Choosing the right input type for your form field.
Another dive into the archives of the www-talk mailing list. This time there are some gems about the origins of the
input element, triggered by the old
Jason breaks down the myths of inputs being tied to device form factors. Instead, given the inherent uncertainty around input, the only sensible approach is progressive enhancement.
Now is the time to experiment with new forms of web input. The key is to build a baseline input experience that works everywhere and then progressively enhance to take advantage of new capabilities of devices if they are available.
You’re supposed to be able to create two-handled sliders with
input type="range" but the browser support isn’t there yet. In the meantime, Lea has created a nice lightweight polyfill.
The greatest form ever made.
A clever technique by Emil to implement the “float label” pattern using CSS. It all hinges on browsers supporting the
:placeholder-shown pseudo-class which, alas, is not universal.
I was hoping that maybe
@supports could come to the rescue (so that a better fallback could be crafted), but that tests for properties and values, not selectors. Damn!
Well, this is timely! Just today I was having a really good natter with Charlotte about using checkboxes, specifically sending multiple values to the server:
You’ll notice that the
namegiven to each of these checkbox
inputelements is the same: “reservation-requested-device”. The square brackets (“”) at the end of the
nameare the magic bit that allows the values of each chosen “reservation-requested-device” checkbox to be submitted as the value of “reservation-requested-device”.
See, I wasn’t sure whether that was just a PHP thing (the only server-side input-handling I’ve had much experience of) or whether it was a more general way of sending multiple values.
Update: It seems that the square brackets are indeed a PHP thing. Multiple values will be sent in any case. See this test case.
A useful primer on which combinations of attributes and values work best for which form fields:
The sad history of
I wish I could share in the closing optimism:
Now imagine the future where Web Components are supported natively, and someone else is allowed to write a <better-input>, an element that is a real, encapsulated DOM element, and not just a div soup. Imagine using this <better-input> that isn’t implemented differently in each browser, that looks the same everywhere, and that probably also knows how to bake you a cherry pie.
But I all I can think is:
Now imagine the future where Web Components are supported natively, and everyone is allowed to write a million variations of <my-idea-of-a-better-input>, an element that is an inaccessible div soup under the hood.
This would be better titled “Futures of texting” but it’s an interesting grab-bag of observations. I’ve always felt that SMS has been overlooked as an input mechanism.
(Conversely, I’ve always felt that voice is really over-rated as input mechanism, but under-rated for output.)
A great investigation into the usability benefits of allowing users to fill in their passwords in plain text.
Major caveat: make sure you still offer the ability to mask passwords too.
Lea wasn’t happy with the lack of styling and extensibility of the datalist element, so she rolled her own lightweight autocomplete/type-ahead widget, and she’s sharing it with the world.
A fantastic collection of short videos from Luke on interaction design for devices of all shapes and sizes.
Make yourself a nice cup of tea, hit “Play all”, sit back, relax and learn from the master.
I really like this interface idea from Brad that provides the utility of input masks but without the accessibility problems.
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.