4 ms·

>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 ago
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 http://www.w3schools.com/HTML/html5_form_input_types.asp
- papsosouid 13y ago
  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.
showerst 13y ago
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.
- quackerhacker 13y ago
  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.
- papsosouid 13y ago
  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.

quackerhacker 13y ago

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 http://www.w3schools.com/HTML/html5_form_input_types.asp

papsosouid 13y ago
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.

showerst 13y ago

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.

quackerhacker 13y ago
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.
papsosouid 13y ago
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.