Hacker News Reader

Comment by quackerhacker | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com