

The Current State of HTML5 Forms - bretthopper
http://wufoo.com/html5/

======
patio11
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
Scribd is ruthlessly efficient with their SEO even though they don't create
linkbait content.

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

------
blehn
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).

~~~
lambda
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> [2]: <http://www.webkit.org/blog/363/styling-
scrollbars/> [3]: <http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/>

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

~~~
sad_hacker
Surprised also by Opera doing so well.

~~~
richbradshaw
Opera has always been ahead on forms, they had implemented most (possibly
all?) of Webforms 2 before it became part of HTML5.

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

------
mrspeaker
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?!

~~~
mryall
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-
elemen...](http://dev.w3.org/html5/spec/Overview.html#the-output-element)

------
mryall
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
I think it is ok to include ff4 considering it will be released tomorrow.

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

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

------
ck2
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>

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

------
Semiapies
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.

------
ggordan
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..

~~~
Raphael
I don't recall Microsoft using anything open source.

~~~
WalterGR
You'll find many references in the following.

<http://www.google.com/search?q=microsoft+uses+open+source>

------
btucker
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> When it should be going to:
<http://wufoo.com/html5/types/2-tel.html>

~~~
chriscoyier
Fixed, thank you.

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

------
Getahobby
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
When has not _not_ been, by that standard?

Things are better than they were ten years ago, at least.

~~~
Getahobby
Oh, I don't know - the chart ten years ago would have had fewer columns. :)

------
nicpottier
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>

They claim a size of ~5K over plain old JQuery and let you write HTML5 form
markup even for IE6.

------
wordchute
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.

------
DjDarkman
And to think some people call IE9 a modern browser.

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

