Forms in HTML5
The HTML5 spec continues to grind inexorably toward publication. I've just spent a while with the latest draft, and at least with respect to forms, I like what I see. Here's a roundup.
(Most of these features are in "Last call for comments" status, so it's likely they'll make the final spec, but everything you're about to read is subject to change.)
-
A couple of the new features are little more than UI sugar, but they're welcome nonetheless. The
autofocusattribute does what it says on the tin. Theplaceholderattribute will display a hint value in a control—e.g., "you@example.com" in an email field—which will disappear when the control receives focus.No more crappy little scripts just to implement these simple UI behaviors—a few keystrokes, and you're done!
-
The
autocompleteattribute (already implemented by some browsers, including Firefox) will allow us to control whether the browser attempts autocompletion of a particular field. Disabling autocompletion is useful when you don't want a particular value (such as a bank customer's username) to be easily discoverable, or when dealing with a one-time entry (such as a CAPTCHA) where it makes little sense to remember the input value.Its natural partner is the
listattribute, which will allow us to suggest possible values for the control. Presumably user agents will be free to implement this as type-ahead autocompletion (à la Google), as a combo box, or in any other way they see fit. -
There's a whole slew of new
<input />types, including calendars, color pickers, numbers, email addresses, and URLs, among others.This dovetails nicely with the new form validation model, which
(in addition to enforcing syntax for values such as email addresses and URLs) will allow us to require a value, test it against an arbitrary regular expression, and restrict numeric values to a specified range and/or a specified granularity. -
Menus, of both the standard and context varieties.
Individual menu items (and buttons, and other UI elements) will be associated with
<command>elements. Presumably—I haven't thoroughly reviewed this part yet—triggering a menu item or other control will fire a DOM event on the associated command; client-side scripts can register event listeners on the command element, and respond without knowing or caring which element originally triggered the request.
In short, HTML's role as a document markup language is expanding to include interface markup as well. This is probably as it should be—there are few pages on the modern web (aside from W3C recommendations and documents repurposed from print) which the existing standards can describe without strain.
Many of the things we now code in JavaScript will be supported natively by browsers—we'll have to write less code, and users will get a faster, richer, more responsive, and more uniform experience. On the other hand, browsers will continue to grow in size and complexity—especially with the just-in-time JavaScript compilation featured in the latest generation, they're looking less and less like document readers, and more and more like runtime environments for applications.
There will undoubtedly be bugs to contend with in the first generation of HTML5 browsers, but hopefully browser makers have learned the lessons of IE6, and will at least attempt to comply with the spec. We still have a few years before the standard is finalized and widely supported, but (especially once CSS3 follows suit) it's going to offer some interesting possibilities.
Comments
No comments yet.