13 ms·

The Current State of HTML5 Forms

126 points by bretthopper 16y ago

wordchute 16y ago
I'm sure it will all work really well in about fifteen years when everyone is talking about HTML6 or whatever - and there will be twice as many browsers to worry about.
lordlarm 16y ago
I'm impressed by Opera, and very disappointed with IE9. To bad one of them is way bigger than the other one.
- mikerg87 16y ago
  I tried with IE9 final. a few more things passed but a lot is still broken. They should probably update the page to reflect that its IE9 final and not one of the betas. still not great.
- sad_hacker 16y ago
  Surprised also by Opera doing so well.
  - richbradshaw 16y ago
    Opera has always been ahead on forms, they had implemented most (possibly all?) of Webforms 2 before it became part of HTML5.
    - mryall 16y ago
      Yes, all these new form features are a massive boost for consistency and usability of forms on the web. Opera is often ahead when it comes to web usability issues like this. Great work, guys.
- Tyrant505 16y ago
  I actually just installed it because of this. I haven't used Opera in years and am excited to try it again.
btucker 16y ago
If anyone from wufoo's around: Beautiful work guys! One tiny typo: The <input type=tel> link on the index page is incorrectly going to: http://wufoo.com/html5/types/1-tel.html http://wufoo.com/html5/types/1-tel.html When it should be going to: http://wufoo.com/html5/types/2-tel.html http://wufoo.com/html5/types/2-tel.html
- chriscoyier 16y ago
  Fixed, thank you.
  - shaggyfrog 16y ago
    There's also no way to get back to the "beginning" from one of these info pages. Neither "the current state of html5 forms" nor the "wufoo" wordmark at the top are links.
mrspeaker 16y ago
According to the chart, IE9 supports just one feature: the output tag. "The <output> element is the semantically correct element for displaying the results of a calculation from form elements." My questions is... why did they decide to implement that one, out of the whole bunch?!
- richbradshaw 16y ago
  I'm guessing their support is just that it defaults to display:block and that you can style it.
- mryall 16y ago
  The <output> element doesn't have many additional semantics on top of a non-semantic element like <div>. All it supports is a special "for" attribute that doesn't require any additional behaviour [1]. IE9 is the first version of IE that doesn't barf on unknown new elements in the DOM, so I suppose they got support for this "for free" without any additional development. [1] http://dev.w3.org/html5/spec/Overview.html#the-output-element http://dev.w3.org/html5/spec/Overview.html#the-output-elemen...
- chriscoyier 16y ago
  The only reason I marked it as "supported" is that it's "supported" like like any other purely semantic tag is (e.g. <nav>) It's just in with the forms stuff because it's specifically for content coming out of form calculations. I didn't even test the "for" attribute stuff, but wouldn't be surprised if that's not supported.
mryall 16y ago
I'm somewhat disappointed when charts like this use pre-release browser versions like Firefox 4 beta. If you're going to compare apples with apples, you have to use released, production versions of each browser for comparison charts. Otherwise, why not include Webkit nightlies and the Chrome dev version? Maybe that would just make Firefox look even further behind.
- timtadh 16y ago
  I think it is ok to include ff4 considering it will be released tomorrow.
- bryanlarsen 16y ago
  Firefox 4 beta 1 was released in July, and the Chrome 6 beta was released in August. One could easily argue that the Firefox late betas are better tested than Chrome releases. (I'm not, but you could). So it's apples and oranges no matter what you do, there's no possible way of comparing apples to apples.
- natmaster 16y ago
  I'm just wondering why they aren't including Firefox 4 and IE 9 final. Both versions are available (though Firefox 'officially' launches tomorrow).
- jerf 16y ago
  "I'm somewhat disappointed when charts like this use pre-release browser versions like Firefox 4 beta." Well, at least browsers release. Unlike HTML only-sorta-5-for-legacy-reasons [1], which gets to just float along making changes whenever. Using pre-release browsers to test a pre-release specification is basically how the system is designed, now. [1]: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/024477.html http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-Dec...
ggordan 16y ago
I'm curious why Microsoft just doesn't drop Trident, and replace it with Webkit. I'm sure it will bring them and endless amount of great publicity. There should really be just one rendering engine. Dare to dream..
- daleharvey 16y ago
  because having one rendering engine for most web users has worked so well previously competition is good
  - ggordan 16y ago
    I agree, competition is great; it spurs innovation. But I don't see how all browsers using the same rendering engine is bad for competition. Are Safari and Chrome not competing? Are they not innovating? Users would still have a choice of browsers, but the web would be a much better place for users, and developers/designers.
    - bzbarsky 16y ago
      Has either Safari or Chrome fixed the known bugs in their CSS selector matching? No, because fixing those is not a priority for the core webkit developers. Is it a good thing for designers for those bugs to be enshrined as a de-facto standard? I don't think so. The fact that other UAs don't have them might serve as pressure on webkit to fix them too. Maybe.
- shaggyfrog 16y ago
  Have you ever known Microsoft to give away control over something as major as a Web browser... not to mention, but to one of its greatest competitors? The overwhelming dominance of a single browser caused big problems on its own. We need healthy competition in this technology marketplace.
  - ggordan 16y ago
    I agree, it will never happen. What are they giving away to it's competitors though? Webkit it open source. They would still have IE.
mbrubeck 16y ago
Firefox 4 actually does support the "accept" attribute on Windows and Linux... just not (yet) on Mac OS X.
blehn 16y ago
On a related note, I think the HTML spec should explicitly define default styles for each type of input. Each input should also be fully customizable with CSS rules (I'm looking at you, radio, checkbox, and select). It's a pain in the ass to make a form look good, and using JS to replace the inputs is a hacky solution. All the major browser makers use custom input styles on their own websites — clearly, inheriting the styles of the operating system is nonsense. (if OS styles are to be inherited, at least make them easy to modify with CSS).
- glenjamin 16y ago
  This is the main reason I cannot see myself using HTML5 form validations - they look awful and inconsistent across user agents.
- lambda 16y ago
  There has been a good deal of talk over the years of making form controls stylable[1]; a few, like buttons, already are, and WebKit has some vendor-specific extensions for things like scrollbars[2]. But it will take quite a bit of work to hash out standards, and a lot of implementation work in all of the major browsers to get it there. The WebKit scrollbars use a whole bunch of pseudo-elements and pseudo-classes, but there's also a possibility that the functionality for reaching inside controls and interacting with their individual parts may be exposed through a shadow DOM[3]. As mentioned in the shadow DOM post, there's a lot of work needed to be done discussing, standardizing, and implementing these features. I'd encourage people interested to get involved on www-style and public-webapps at the W3C, and the WHATWG mailing list (avoid public-html at the W3C, it appears to be purely political at this point), or get involved in one of the open-source browser engines implementing experimental versions of this stuff to give a starting point for discussion. [1]: http://goo.gl/i1eL9 http://goo.gl/i1eL9 [2]: http://www.webkit.org/blog/363/styling-scrollbars/ http://www.webkit.org/blog/363/styling-scrollbars/ [3]: http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/ http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/
- rimantas 16y ago
  HTML should not specify styles for anything. If you want that from HTML you don't understand what HTML is. Nothing stops you from targeting different inputs with CSS right now with attribute selectors (e.g. input[type="url"]). As for whether it is a good idea to style inputs differently from defaults users are used to, that's still a topic for discussion.
speleding 16y ago
Very interesting page, too bad the take away for me is... that I won't be able to use any of those nifty new features for the foreseeable future since a sizable chunk of the audience will have IE.
- jp_sc 16y ago
  Why? How come using an <input type="email"> —that in Safari Mobile activates a custom keyboard and in IE si treated like a regular input— it's such an improbable scenario?
patio11 16y ago
This is the best SEO project I've ever seen a YC company do. (Brief rationale: it is much more linkable than Wufoo proper, targets a link-rich audience, is beautiful, is evergreen, parallelizes over a sizable basket of keywords, is squarely topical for the business, leverages earned rep as domain experts, etc.)
- sachinag 16y ago
  Scribd is ruthlessly efficient with their SEO even though they don't create linkbait content.
  - sireat 16y ago
    Sribd are ruthless, but their SEO is not human oriented. Good (as in both ethically good and efficient) SEO should be good for both humans and robots. That is the kind of stuff Wufoo has done here and the kind of stuff patio11 has been doing for years.
- al_james 16y ago
  Agreed. It shows that you can achieve SEO goals whilst providing informative and valuable content. I hope that as google cracks down on 'poor quality content' sites, content rich, but SEO-aware, articles like this will be rewarded.
- bobds 16y ago
  Minus points for using /html5 as the url instead of /html5-forms.
Getahobby 16y ago
When you need to have charts like this for almost every single html5 feature then the current state of web development is a DISASTER.
- Semiapies 16y ago
  When has not not been, by that standard? Things are better than they were ten years ago, at least.
  - Getahobby 16y ago
    Oh, I don't know - the chart ten years ago would have had fewer columns. :)
Semiapies 16y ago
There are a lot of javascript libraries and plugins for form validation, but are there any for simply providing validation and filtering functionality for the browsers that don't support all the HTML5 form features? Something that detected whether a feature worked and, if not, set up a fallback would be very useful.
nicpottier 16y ago
For what looks like a pretty sweet library to take care of graceful degradation, take a look at JQuery Tools: http://flowplayer.org/tools/release-notes/index.html#form http://flowplayer.org/tools/release-notes/index.html#form They claim a size of ~5K over plain old JQuery and let you write HTML5 form markup even for IE6.
DjDarkman 16y ago
And to think some people call IE9 a modern browser.
ck2 16y ago
Did you know there isn't a single mobile device that supports "contenteditable" (designmode) yet? Not even android with Chrome, I was surprised (and it's nowhere in wufoo's lists). http://caniuse.com/contenteditable http://caniuse.com/contenteditable So no rich-wysiwyg forms for mobile (unless you can use Flash or native interface somehow) and nothing else likely in 2011 - sad to see.
- andybak 16y ago
  Webkit barely supports contenteditable on the desktop. For some reason the fact that it's used as on every WYSIWYG editor in the frikkin' world doesn't make it high enough priority for a fix...
  - ck2 16y ago
    It seems to work fine for my projects, at least with iframes in designMode, I avoid directly dealing with DIVs. But I wonder why they chop it out of mobile Safari and mobile Chrome, maybe it adds too much to the executable size.
- tene 16y ago
  That's inaccurate. WebOS (even 1.x) supports it just fine. The demo linked from there ( http://html5demos.com/contenteditable http://html5demos.com/contenteditable ) works just fine on my old Prē, including the local storage.
blickly 16y ago
I think maybe I'm missing something obvious, but why does the chart jump from Chrome 6 to Chrome 10?

126 points by bretthopper 16y ago

I'm sure it will all work really well in about fifteen years when everyone is talking about HTML6 or whatever - and there will be twice as many browsers to worry about.

lordlarm 16y ago

I'm impressed by Opera, and very disappointed with IE9. To bad one of them is way bigger than the other one.

mikerg87 16y ago
I tried with IE9 final. a few more things passed but a lot is still broken. They should probably update the page to reflect that its IE9 final and not one of the betas. still not great.
sad_hacker 16y ago
Surprised also by Opera doing so well.
- richbradshaw 16y ago
  Opera has always been ahead on forms, they had implemented most (possibly all?) of Webforms 2 before it became part of HTML5.
  - mryall 16y ago
    Yes, all these new form features are a massive boost for consistency and usability of forms on the web. Opera is often ahead when it comes to web usability issues like this. Great work, guys.
Tyrant505 16y ago
I actually just installed it because of this. I haven't used Opera in years and am excited to try it again.

btucker 16y ago

If anyone from wufoo's around: Beautiful work guys! One tiny typo: The <input type=tel> link on the index page is incorrectly going to: http://wufoo.com/html5/types/1-tel.html http://wufoo.com/html5/types/1-tel.html When it should be going to: http://wufoo.com/html5/types/2-tel.html http://wufoo.com/html5/types/2-tel.html

chriscoyier 16y ago
Fixed, thank you.
- shaggyfrog 16y ago
  There's also no way to get back to the "beginning" from one of these info pages. Neither "the current state of html5 forms" nor the "wufoo" wordmark at the top are links.

mrspeaker 16y ago

According to the chart, IE9 supports just one feature: the output tag. "The <output> element is the semantically correct element for displaying the results of a calculation from form elements." My questions is... why did they decide to implement that one, out of the whole bunch?!

richbradshaw 16y ago
I'm guessing their support is just that it defaults to display:block and that you can style it.
mryall 16y ago
The <output> element doesn't have many additional semantics on top of a non-semantic element like <div>. All it supports is a special "for" attribute that doesn't require any additional behaviour [1]. IE9 is the first version of IE that doesn't barf on unknown new elements in the DOM, so I suppose they got support for this "for free" without any additional development. [1] http://dev.w3.org/html5/spec/Overview.html#the-output-element http://dev.w3.org/html5/spec/Overview.html#the-output-elemen...
chriscoyier 16y ago
The only reason I marked it as "supported" is that it's "supported" like like any other purely semantic tag is (e.g. <nav>) It's just in with the forms stuff because it's specifically for content coming out of form calculations. I didn't even test the "for" attribute stuff, but wouldn't be surprised if that's not supported.

mryall 16y ago

I'm somewhat disappointed when charts like this use pre-release browser versions like Firefox 4 beta. If you're going to compare apples with apples, you have to use released, production versions of each browser for comparison charts. Otherwise, why not include Webkit nightlies and the Chrome dev version? Maybe that would just make Firefox look even further behind.

timtadh 16y ago
I think it is ok to include ff4 considering it will be released tomorrow.
bryanlarsen 16y ago
Firefox 4 beta 1 was released in July, and the Chrome 6 beta was released in August. One could easily argue that the Firefox late betas are better tested than Chrome releases. (I'm not, but you could). So it's apples and oranges no matter what you do, there's no possible way of comparing apples to apples.
natmaster 16y ago
I'm just wondering why they aren't including Firefox 4 and IE 9 final. Both versions are available (though Firefox 'officially' launches tomorrow).
jerf 16y ago
"I'm somewhat disappointed when charts like this use pre-release browser versions like Firefox 4 beta." Well, at least browsers release. Unlike HTML only-sorta-5-for-legacy-reasons [1], which gets to just float along making changes whenever. Using pre-release browsers to test a pre-release specification is basically how the system is designed, now. [1]: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/024477.html http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-Dec...

ggordan 16y ago

I'm curious why Microsoft just doesn't drop Trident, and replace it with Webkit. I'm sure it will bring them and endless amount of great publicity. There should really be just one rendering engine. Dare to dream..

daleharvey 16y ago
because having one rendering engine for most web users has worked so well previously competition is good
- ggordan 16y ago
  I agree, competition is great; it spurs innovation. But I don't see how all browsers using the same rendering engine is bad for competition. Are Safari and Chrome not competing? Are they not innovating? Users would still have a choice of browsers, but the web would be a much better place for users, and developers/designers.
  - bzbarsky 16y ago
    Has either Safari or Chrome fixed the known bugs in their CSS selector matching? No, because fixing those is not a priority for the core webkit developers. Is it a good thing for designers for those bugs to be enshrined as a de-facto standard? I don't think so. The fact that other UAs don't have them might serve as pressure on webkit to fix them too. Maybe.
shaggyfrog 16y ago
Have you ever known Microsoft to give away control over something as major as a Web browser... not to mention, but to one of its greatest competitors? The overwhelming dominance of a single browser caused big problems on its own. We need healthy competition in this technology marketplace.
- ggordan 16y ago
  I agree, it will never happen. What are they giving away to it's competitors though? Webkit it open source. They would still have IE.

mbrubeck 16y ago

Firefox 4 actually does support the "accept" attribute on Windows and Linux... just not (yet) on Mac OS X.

blehn 16y ago

On a related note, I think the HTML spec should explicitly define default styles for each type of input. Each input should also be fully customizable with CSS rules (I'm looking at you, radio, checkbox, and select). It's a pain in the ass to make a form look good, and using JS to replace the inputs is a hacky solution. All the major browser makers use custom input styles on their own websites — clearly, inheriting the styles of the operating system is nonsense. (if OS styles are to be inherited, at least make them easy to modify with CSS).

glenjamin 16y ago
This is the main reason I cannot see myself using HTML5 form validations - they look awful and inconsistent across user agents.
lambda 16y ago
There has been a good deal of talk over the years of making form controls stylable[1]; a few, like buttons, already are, and WebKit has some vendor-specific extensions for things like scrollbars[2]. But it will take quite a bit of work to hash out standards, and a lot of implementation work in all of the major browsers to get it there. The WebKit scrollbars use a whole bunch of pseudo-elements and pseudo-classes, but there's also a possibility that the functionality for reaching inside controls and interacting with their individual parts may be exposed through a shadow DOM[3]. As mentioned in the shadow DOM post, there's a lot of work needed to be done discussing, standardizing, and implementing these features. I'd encourage people interested to get involved on www-style and public-webapps at the W3C, and the WHATWG mailing list (avoid public-html at the W3C, it appears to be purely political at this point), or get involved in one of the open-source browser engines implementing experimental versions of this stuff to give a starting point for discussion. [1]: http://goo.gl/i1eL9 http://goo.gl/i1eL9 [2]: http://www.webkit.org/blog/363/styling-scrollbars/ http://www.webkit.org/blog/363/styling-scrollbars/ [3]: http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/ http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/
rimantas 16y ago
HTML should not specify styles for anything. If you want that from HTML you don't understand what HTML is. Nothing stops you from targeting different inputs with CSS right now with attribute selectors (e.g. input[type="url"]). As for whether it is a good idea to style inputs differently from defaults users are used to, that's still a topic for discussion.

speleding 16y ago

Very interesting page, too bad the take away for me is... that I won't be able to use any of those nifty new features for the foreseeable future since a sizable chunk of the audience will have IE.

jp_sc 16y ago
Why? How come using an <input type="email"> —that in Safari Mobile activates a custom keyboard and in IE si treated like a regular input— it's such an improbable scenario?

patio11 16y ago

This is the best SEO project I've ever seen a YC company do. (Brief rationale: it is much more linkable than Wufoo proper, targets a link-rich audience, is beautiful, is evergreen, parallelizes over a sizable basket of keywords, is squarely topical for the business, leverages earned rep as domain experts, etc.)

sachinag 16y ago
Scribd is ruthlessly efficient with their SEO even though they don't create linkbait content.
- sireat 16y ago
  Sribd are ruthless, but their SEO is not human oriented. Good (as in both ethically good and efficient) SEO should be good for both humans and robots. That is the kind of stuff Wufoo has done here and the kind of stuff patio11 has been doing for years.
al_james 16y ago
Agreed. It shows that you can achieve SEO goals whilst providing informative and valuable content. I hope that as google cracks down on 'poor quality content' sites, content rich, but SEO-aware, articles like this will be rewarded.
bobds 16y ago
Minus points for using /html5 as the url instead of /html5-forms.

Getahobby 16y ago

When you need to have charts like this for almost every single html5 feature then the current state of web development is a DISASTER.

Semiapies 16y ago
When has not not been, by that standard? Things are better than they were ten years ago, at least.
- Getahobby 16y ago
  Oh, I don't know - the chart ten years ago would have had fewer columns. :)

Semiapies 16y ago

There are a lot of javascript libraries and plugins for form validation, but are there any for simply providing validation and filtering functionality for the browsers that don't support all the HTML5 form features? Something that detected whether a feature worked and, if not, set up a fallback would be very useful.

nicpottier 16y ago

For what looks like a pretty sweet library to take care of graceful degradation, take a look at JQuery Tools: http://flowplayer.org/tools/release-notes/index.html#form http://flowplayer.org/tools/release-notes/index.html#form They claim a size of ~5K over plain old JQuery and let you write HTML5 form markup even for IE6.

DjDarkman 16y ago

And to think some people call IE9 a modern browser.

ck2 16y ago

Did you know there isn't a single mobile device that supports "contenteditable" (designmode) yet? Not even android with Chrome, I was surprised (and it's nowhere in wufoo's lists). http://caniuse.com/contenteditable http://caniuse.com/contenteditable So no rich-wysiwyg forms for mobile (unless you can use Flash or native interface somehow) and nothing else likely in 2011 - sad to see.

andybak 16y ago
Webkit barely supports contenteditable on the desktop. For some reason the fact that it's used as on every WYSIWYG editor in the frikkin' world doesn't make it high enough priority for a fix...
- ck2 16y ago
  It seems to work fine for my projects, at least with iframes in designMode, I avoid directly dealing with DIVs. But I wonder why they chop it out of mobile Safari and mobile Chrome, maybe it adds too much to the executable size.
tene 16y ago
That's inaccurate. WebOS (even 1.x) supports it just fine. The demo linked from there ( http://html5demos.com/contenteditable http://html5demos.com/contenteditable ) works just fine on my old Prē, including the local storage.

blickly 16y ago

I think maybe I'm missing something obvious, but why does the chart jump from Chrome 6 to Chrome 10?