

A Guide to the New HTML5 Form Input Types - aytekin
http://sixrevisions.com/html5/new-html5-form-input-types/

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

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

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

------
johneth
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](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."

------
hopeless
I find the Wufoo guide to be more useful:
[http://www.wufoo.com/html5](http://www.wufoo.com/html5)

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

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

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

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

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

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

~~~
ht_th
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?

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

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

