The Current State of HTML5 Forms | Hacker News Reader

The Current State of HTML5 Forms

wufoo.com

126 pointsbretthopper56 comments

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

Scribd is ruthlessly efficient with their SEO even though they don't create linkbait content.

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.

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.

Minus points for using /html5 as the url instead of /html5-forms.

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

This is the main reason I cannot see myself using HTML5 form validations - they look awful and inconsistent across user agents.

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/

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'm impressed by Opera, and very disappointed with IE9. To bad one of them is way bigger than the other one.

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.

Surprised also by Opera doing so well.

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

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.

I actually just installed it because of this. I haven't used Opera in years and am excited to try it again.

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

I'm guessing their support is just that it defaults to display:block and that you can style it.

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

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

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.

I'm just wondering why they aren't including Firefox 4 and IE 9 final. Both versions are available (though Firefox 'officially' launches tomorrow).

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

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?

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

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.

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

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.

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 Prē, including the local storage.

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.

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

because having one rendering engine for most web users has worked so well previously

competition is good

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.

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.

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.

Control.

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.

And if they don't want to control it (by not working upstream), then we have the same problem now since they will act differently.

What is sad that MS had it's own Tasman engine used in IE5 for Mac. Why didn't MS port that to Windows?

I don't recall Microsoft using anything open source.

JQuery

You'll find many references in the following.

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

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

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

Fixed, thank you.

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.

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

When has not not been, by that standard?

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

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

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.

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.

And to think some people call IE9 a modern browser.

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

Reply on news.ycombinator.com