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.)
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.
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).
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.
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.
Note that for some inputs (e.g. type="file") different UAs make them look totally different. And they might need to look different based on the input modality and so forth.
We could specify a forced lowest-common-denominator behavior of some sort, but that seems like a disservice to users.
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.
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.
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?!
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.
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.
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.
"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.
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.
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.
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?
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.
Right now they control Trident as they like. A shift to WebKit would mean ceding a lot of that control to Apple and Google and all the other WebKit contributors/maintainers.
Well, one reason might be that they care about not having buggy code. You may laugh, but for the standards IE9 claims to implement it does a very good job. Much better than Webkit, in my testing.
> There should really be just one rendering engine.
No. That's really a terrible idea, because different rendering engine consumers have different priorities.
Luckily, even "webkit" has a number of forks that are somewhat incompatible for precisely that reason. So we're in no danger of this "one rendering engine" thing.
(A note: while we've already been close to having one rendering engine with a priority of "change nothing", having one with pretty much any other priority set is no better; those priorities will be wrong for _some_ consumer.)
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.
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.
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.
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.
That's inaccurate. WebOS (even 1.x) supports it just fine. The demo linked from there ( http://html5demos.com/contenteditable ) works just fine on my old Prē, including the local storage.
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...
