Re:A Guide to the New HTML5 Form Input Types
by beaumartinez on Friday June 07, 2013 @09:15AM
(#5838661)
You mean input[type=url] right? My internal CSS parser broke for a moment whilst I read that.
Re:A Guide to the New HTML5 Form Input Types
by quackerhacker on Friday June 07, 2013 @09:19AM
(#5838676)
lol, yup
Re:A Guide to the New HTML5 Form Input Types
by papsosouid on Friday June 07, 2013 @10:16AM
(#5839003)
>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.
Re:A Guide to the New HTML5 Form Input Types
by showerst on Friday June 07, 2013 @10:38AM
(#5839133)
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.
Re:A Guide to the New HTML5 Form Input Types
by quackerhacker on Friday June 07, 2013 @10:49AM
(#5839196)
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 , [email protected] , 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.
Re:A Guide to the New HTML5 Form Input Types
by papsosouid on Friday June 07, 2013 @04:09PM
(#5841371)
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.
Re:A Guide to the New HTML5 Form Input Types
by quackerhacker on Friday June 07, 2013 @10:27AM
(#5839053)
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
Re:A Guide to the New HTML5 Form Input Types
by papsosouid on Friday June 07, 2013 @04:11PM
(#5841399)
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.
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 :)