farblog

Between December 2003 and August 2004, my pet ‘project’ was contributing to the discussion around the WHATWG’s Web Forms 2 spec. I’m still subscribed to the mailing lists, but as I’m probably up to about two years of unread messages by now, I can’t exactly say that I’m up to date.

WHATWG stands for “Web Hypertext Application Technology Working Group”, and sprung out of a disagreement as to the future of HTML/XHTML, with the major browser vendors on one side and W3C on the other. At the time, W3C thought that the future of the Web was XHTML 2.0, a non-backward-compatible markup language closer to DocBook in spirit than to HTML, and, well, the browser manufacturers (particularly Opera and Mozilla) didn’t.

But Web Forms 2 was interesting: an incremental evolution of HTML4’s forms, simple to grasp, and almost completely backward-compatible. Here’s an example:

Let’s say you have a form that requests a name, email address, and optional date of birth. Instead of implementing complex client-side Javascript validation and datepicker controls, you just write this instead:

Name: <input name="name" required="required">
Email: <input name="email" type="email" required="required">
Birthdate: <input name="birthdate" type="date">

Now the browser can perform the validation declaratively, and (more importantly) present standard ‘pick an email address’ and ‘pick a date’ controls for the email and birthdate fields. You still, as always, need server-side validation to protect against malicious clients, and you almost certainly also need to retain your client-side validation for downlevel clients.

Web Forms 2 also includes improvements to other controls (select more than one file to upload at once — revolutionary!), better DOM interfaces, and some nice models for partial initialisation of forms and handling repeating form controls better, but it was the strongly-typed form controls that always seemed to me to have the most potential.

The WHATWG later broadened its work to include a ‘Web Applications’ spec that has since evolved into what is now known as HTML5 — the goal being to provide a complete specification for how to implement a web browser in the modern would (in other words, a specification that doesn’t start “First, reverse-engineer your competition…”).

But by then, I was beginning to run out of steam, partly because of the pressures of work at the time, and partly because I couldn’t sustain my enthusiasm — people had been employed to add an XForms module to Mozilla, but no-one seemed interested in implementing Web Forms 2, and I worried that the much more grandiose plan to develop a complete successor to HTML4 — rather than push for implementation of the largely self-contained Web Forms 2 component — would delay any chance of implementing the parts that I thought would bring the biggest improvement to the web user experience.

That’s why I’m particularly excited to see that Opera 9 now appears to provide an experimental implementation of part of Web Forms 2. There are also client-side Javascript ‘plug-ins’ that have been developed to support parts of the specification on existing browsers, both for Internet Explorer and for other browsers, so you can write some Web Forms 2 code right now!

For my part, I’m glad that the WHATWG effort has finally borne some visible fruit beyond the (truly excellent) specifications and backend work that’s already gone into Firefox and Opera. HTML4 is nearly ten years old now, depending on how you count it, and we desperately need a better browsing experience.

As for me, I’m unsubscribing. There’s only so long I can pretend that I’m going to get back to something I’ve abandoned for so long…

See also: this article on Dev.Opera that contains some more Web Forms 2 examples.