5 ms·
A Guide to the New HTML5 Form Input Types
- smackfu 13y agoThey are good for mobile and fairly useless on desktop browsers.
- ht_th 13y agoWhy? Using them doesn't hurt as they fallback to the text input type. But semantically the code makes more sense as it is more specific, and for those browsers that don't support them, you could fall back on using some javascript to get similar functionality, if you're so inclined. Of course, these elements will look differently on different platforms/browsers, but for a lot of applications that doesn't matter. Maybe, in the next version/iteration of HTML they make these things a bit more style-able?
- smackfu 13y agoThe argument is that support on desktop is so spotty that you are going to have to implement it in JS/HTML anyways. A bare text input field is not sufficient for something like a date or color picker, and is it really better semantically if you have to hide the field entirely if the input sub-type isn't supported? Then if you are going to implement a custom version, it's easier to just use that on all browsers, since you can style it properly, and you don't have the risk of it changing under you as browsers add support in random version updates.
- lucian1900 13y agoThey're great on desktop browsers that support them: I get the same widget everywhere, instead of having to deal with stupidly different ones.
- papsosouid 13y agoYou mean "most desktop browsers are fairly useless". Go complain and get them to fix it. Html5 inputs are very old, there is no excuse for "modern" browsers not to support them. It is much better for users if they get the same, consistent date picking widget everywhere, rather than a different, partially working maybe sometimes javascript version on every site.
- dgreensp 13y agoThe problem with these inputs is how do you style them or customize the UX? For example, how do you style an element that is a color swatch on some browsers and a text field on others?
- kmfrk 13y agoUnsupported input types default to input type="text", so you can just use a JS polyfill that detects the returned input field and acts accordingly.
- dsego 13y agoYou don't. Form elements were never really meant to be styled. That's why there are so hard to style and get a consistent look across all browsers. Of course, that doesn't stop people, so all sorts of hack are employed, many include javascript that actually replaces the native element with a jumble of html elements to re-create the designer's holy vision.
- smackfu 13y agoIt just seems like it ends up making these useful for utility stuff, but will just get ignored for most real projects. It's 2013, the idea that anything should not be able to be styled is ignoring the real world.
- GhotiFish 13y agoNo, having identifiable form elements is freaking important, computers are hard enough for a novice to learn without the basic idioms change shape and meaning because designers want to get creative. The real world needs consistent form inputs. Also. Damn you firefox, Implement the bloody date input.
- acdha 13y agoYou use a JavaScript polyfill which handles browsers which don't yet support them. For example, I recently launched a project using <input type=range> with a [modernizr.load](http://modernizr.com/docs/#load http://modernizr.com/docs/#load) test which uses https://github.com/freqdec/fd-slider https://github.com/freqdec/fd-slider if the browser doesn't have native support. As for styling the native controls, I generally recommend thinking twice about that as the usability benefits of having a familiar standard control are significant but you should read up on the Shadow DOM and the emerging CSS support for it: http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/ http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom&#x...;
- quackerhacker 13y ago>reduce our reliance on client-side- and server-side-scripting for validating common data types like dates, email addresses, and URLs Like what's shown in the article, the main purposes for these new additions is for ui/ux. Devs should still rely on validation scripting prior to a form submission (js) and processing (server side). Although I do know we can implement patterns on the inputs like pattern="[A-Za-z0-9]*" , if your form is submitted with js, it's a good idea to still run some simple validations. (Ex. in chrome, I had a 'required' markup in a hidden input that is suppose to show after a certain field in a form, I encountered form submission problems, even after the area was visible.) On a side note...I didn't know about the url [input=type], thanks for that one :)
- deleted 13y ago[deleted]
- beaumartinez 13y agoYou mean input[type=url] right? My internal CSS parser broke for a moment whilst I read that.
- quackerhacker 13y agolol, yup
- papsosouid 13y ago>Devs should still rely on validation scripting prior to a form submission (js) Why? Adding redundant code that doesn't solve a problem is always a bad idea.
- quackerhacker 13y agoMost users/visitors use a variety of browsers. I agree in reducing code overhead, but cross browser compatibility is still the main problem[0] with relying solely on these HTML5 features (the OP touches on that in his article). [0] http://www.w3schools.com/HTML/html5_form_input_types.asp http://www.w3schools.com/HTML/html5_form_input_types.asp
- hopeless 13y agoI find the Wufoo guide to be more useful: http://www.wufoo.com/html5 http://www.wufoo.com/html5
- deleted 13y ago[deleted]
- raldi 13y agoI like how the URL input type not only spellchecks its contents, but also helpfully marks "http" as a misspelling.
- matt__ring 13y agoI've re-entered the world of web apps recently & think this is excellent!
- deleted 13y ago[deleted]
- johneth 13y agoAs somebody who's currently making a web app that makes use of a variety of form input types, HTML5 form inputs are great. I would also add a recommendation for Select2 - http://ivaynberg.github.io/select2 http://ivaynberg.github.io/select2 - "Select2 is a jQuery based replacement for select boxes. It supports searching, remote data sets, and infinite scrolling of results."