Coffee on the Keyboard

I shouldn’t imply that I don’t like HTML5. I don’t like certain parts of it—the redundant new elements that add no functionality and are of little use except to A List Apart. But other parts of the spec are very exciting. Forms, in particular, are getting a much-needed facelift.

Forms will be able to require the user-agent to do pre-submission validation. Obviously we can’t rely on this for security reasons, but it will save us from writing JavaScript validation scripts and give users a better experience with our forms.

And the validation is fairly robust. <input/> elements gain an attribute called pattern, which accepts a simple regular expression, like "[A-E][0-9]{7}".

But you probably won’t need the pattern attribute very often, since there is a whole slew of new types that the UA will be expected to provide controls for, and validate. Crucial types, like email and url, and difficult types like datetime-local and color.

jQuery UI is great, but it doesn’t compare to this kind of power.

I only realized the sorry state of our current form controls very recently, after getting an iPhone. Built-in form fields on the iPhone can trigger different input methods. A field, like ZIP code, that accepts only numbers, opens the keyboard to the numbers first. A field that wants a URL can open a keyboard with a .com button to save time. But web pages can’t do this. They can only say that an input accepts arbitrary text.

For mobile or touch-enabled UAs, knowing that you can open a keypad instead of a full keyboard is a great step forward. For everyone, having date and color pickers built into the UA means saving both developers’ and users’ time. Less time to build and less time to download, consistent experience in the UA across web sites.

Forms also get a new event, input, which is a little like the current change event, except you don’t need to wait for the element to lose focus for the event to fire. That’s just useful.

Controls get new methods, stepUp() and stepDown(), to enable, for example, very fast forward/backward selection on a date input.

The last fun addition I’ll mention (go read the links, they’re all to the same page) is the autocomplete attribute. It doesn’t do what you hope it does. What it does is specify to the UA that it should not remember and suggest values for this input. It lets the UX designer decide whether to use Firefox or IE’s built-in autocomplete on a per-field basis. Useful. (Not as useful as, say, an autocompleteUrl attribute that could load some JSON or XML, but still useful.)

Building forms is going to be so, so much better once these are widely support.

A day or so ago, Adrian Bateman, from Microsoft’s IE team, posted his team’s thoughts on the current draft of the HTML5 spec.

Reading it is brutal. Bateman takes issue with basically everything added since HTML4. He goes through and individually criticizes many of the new tags, sometimes with extremely detailed, multi-paragraph critiques. I guess this is what happens when you’re not sufficiently involved at the beginning.

Of course, there is still plenty of time to complain, since the HTML5 spec won’t reach its final stage until 2022.

Bateman and the IE team, even while sounding like they don’t even want HTML5, do bring up a few things that have been bothering me about the spec.

Let me be very clear: I think new tags like <audio> and <video> are wonderful. Breaking the Adobe monopoly is great. There are still some issues (refusing to specify a codec meaning you can’t build support into the browser, for instance) but those types of tags are going to help push the web to a better place.

The parts that bother me are the new, highly touted “structural” tags, like <header>, <footer>, <section>, and worst, <article> and <aside>. (more…)