This looks like a nifty take on the ol’ using-labels-like-placeholders pattern for forms. I still prefer to have a label visible at all times, but this seems like a nice compromise.
A wonderful piece by Ethan taking issue what the criticism that responsive design is over-reliant on screen size. Instead, he says, it begins with screen size, but there’s no limit to where we can go from there.
Responsive design might begin with the screen, but it doesn’t end there.
This is wonderful stuff! I’m a big fan of the
datalist element but I hadn’t realised how it could be combined with
input types like
Cennydd uses the word “select” as an input-neutral term for what we might be tempted to call clicks or taps. Personally, I like the term “choose”, although that word might have too much intent bundled with it.
A great piece by Jason analysing the ever-blurring lines between device classes.
Mind you, there is one question he doesn’t answer which would help clear up his framing of the situation. That question is:
What’s a web app?
Andrea looks at support for HTML5 input types in IE10 Mobile.
I concur completely with Luke’s assessment here. Most password-masking on the web is just security theatre. Displaying password inputs by default (but with an option to hide) should be the norm.
This looks like a handy way of enhancing forms to have input masks (Luke W. would approve). Right now it’s a jQuery plug-in but I’m sure someone as smart as you would be able to create a standalone version, right?
Bill Buxton’s collection of input devices going back thirty years.
This looks like a nice progressive enhancement pattern: convert a select element into an auto-completing input element (a country selector in this case).
A handy list of regular expressions that you can use in the new pattern attribute on the input element in HTML5.
Eric explores the dark cabbalistic world of attempting to style form controls. This explains why he doesn't use the universal selector for resetting default styles.