A Guide to the New HTML5 Form Input Types | Hacker News Reader

A Guide to the New HTML5 Form Input Types

sixrevisions.com

63 pointsaytekin24 comments

>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 :)

You mean input[type=url] right? My internal CSS parser broke for a moment whilst I read that.

lol, yup

>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.

Most 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

Cross browser compatibility is fine without putting in javascript (which people frequently fail to test cross browser and ends up being wrong and broken). Modern browsers get the best experience, old crap browsers get a degraded but still functional experience. You don't need to try to make everything the same everywhere, just make it work everywhere.

UX. It's much faster to have JS return an instant error because you forgot an @ in your email than to have to do a roundtrip to the server and watch the page flicker (reload), especially on a crappy connection.

Not so big a deal on one field, but if you have 5+ errors in a long form, it can add up.

You of course still have to validate server-side to stop ancient browsers or people trying to hack your site from submitting bad data.

Browsers which support HTML5 form validation are "suppose," to validate the input prior to submitting the forms. I think this trended a bit ago here on HN about email validation...even if you do a <input type="email">, a user can still submit an email in these forms (blah@you , 123@12.zz , 12345@localhost ,...get the idea).

Another quirk about form validation in HTML5 is the forms won't get validated UNTIL the user submits the form and then the browser may highlight the error in consecutive order (1 at a time o_O), imagine your poor UX for a user that has multiple errors.

Except that the form is already validated client side by the input elements, that's the point. It doesn't make any sense to validate it twice client side.

As 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 - "Select2 is a jQuery based replacement for select boxes. It supports searching, remote data sets, and infinite scrolling of results."

I find the Wufoo guide to be more useful: http://www.wufoo.com/html5

I like how the URL input type not only spellchecks its contents, but also helpfully marks "http" as a misspelling.

The 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?

Unsupported input types default to input type="text", so you can just use a JS polyfill that detects the returned input field and acts accordingly.

You 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.

It 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.

No, 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.

You 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) test which uses 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&#x...;

They are good for mobile and fairly useless on desktop browsers.

Why? 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?

The 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.

They're great on desktop browsers that support them: I get the same widget everywhere, instead of having to deal with stupidly different ones.

You 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.

I've re-entered the world of web apps recently & think this is excellent!

Reply on news.ycombinator.com