XHTML2: not dead

Late last week, just before the US holiday weekend, W3C management announced that they had decided to no longer supply resources for XHTML2 after its current charter runs out at the end of this year. However, this doesn't mean that work on XHTML2 will stop, or that XHTML2 is dead, just that the work will carry on elsewhere.

The fact that W3C no longer has the resources to support XHTML2 does not mean that the need for it goes away, nor that the companies working on it want to stop. To this end we are now working on where to take the work in order to complete it.

What this does mean is that we no longer have to adhere to the membership rules of W3C to do the work, so if you want to get involved in the future work on XHTML2, please get in touch, at xhtml2 at future-web dot org.

The background

Although a couple of members within W3C have actively campaigned to close the group, many have supported the work. Last spring, the W3C advisory committee in fact voted to continue resources to the XHTML2 WG. And no surprise, because the XHTML2 WG has done a lot of good work.

W3C working groups work within charters. When the group is first created, it gets a charter that outlines and defines its areas of work. The working group normally may not stray outside the bounds of the charter. The original XHTML charter stated the purpose as "To develop the next generation of HTML as a suite of XML tag sets with a clean migration path from HTML 4.0", and that is exactly what the group did.

Modularization

The underlying technology that the group developed to serve this purpose was XHTML Modularization. This is actually just a methodology: a standard definition of how to define and plug tag sets (modules) together. There are versions of this methodology at least for DTDs, XML Schema and RelaxNG.

The nice part of this approach is that you can define a new module, and immediately plug it into an existing (modularized) language. That was how the XHTML+RDFa language was produced so quickly: we just produced the module, plugged it in, and hey presto! you have the complete new language. Similarly, any other language defined with modularisation can also add the new module with little work. And another nice part is that if a module gets changed or updated, or the host language gets modified or changed, it is little work to update the languages.

Modularization in itself is of course only of interest to people and groups who produce languages, not to users of those languages. But still, apart from the XHTML group among others Jabber has used it, as has Epub, the Open Book Format used on the iphone, the Sony book reader, and others.

Based on modularization, the group then produced modules that independently could get implemented, tried out and adopted. The term "XHTML2" then covers the final packaging of all those modules together.

The Design

The group went about its work by evaluating current web practices and guidelines, and talking to representative communities, trying to identify areas that were considered problematic. We ended up with a list that included amongst others Ease of authoring, Forms, Internationalization, Usability, Device independence, Accessibility, Extensibility, and User-defined semantics.

Some of these (such as forms) have produced a module of their own, while others (such as device independence) are distributed over the whole language. Many of the XHTML2 modules have been around, implemented and adopted for a long time now. Most are finished. For instance:

• XForms: this module was so demanding of the time of the people producing it that it got spun off as a separate working group; that notwithstanding, it is still a central part of XHTML2. XForms is in use in the US government, many UK local government sites are powered using Xforms, XForms is a central part of ODF, the Open Document Format used in OpenOffice, XForms is being used for configuring hardware, building ships, tracking diseases, is embedded in hardware, and in hundreds of other applications. We have convincing evidence that using XForms has reduced the effort needed to produce an application by an order of magnitude.
  
• RDFa: this is the most-recently finished module. Again it is being used by the US and UK governments, and supported by amongst many others by Yahoo and Google.
• Role: While outwardly a very simple module, for a range of uses, its initial aim was to support accessibility, and WAI-ARIA have adopted this for their work.
• XML Events: this is an improved way of catching events, replacing the onclick style in HTML. As the name suggests, it is applicable to any XML language. and has for instance been adopted by SVG.
• Access: This is a generalisation of accesskey, and allows you to assign navigation events to parts of the page. Although accesskey was designed for accessibility, it is also widely used for mobile applications.
  

So there remains little more to be done. There are a couple more modules that need to be finished before XHTML2 can be signed off on, principally the hypertext and embedding modules. Ian Hickson sings the praise of those modules elsewhere.

What about browsers?

The essence of XHTML2 is that you author a page, and the user gets the user experience defined by that page. There are many ways to achieve that experience, and native implementation in the browsers is not a pre-requisite. Many successful Web technologies are not implemented in the browser: for instance PHP and Dojo to name but two. Techniques such as server-side transformation and unobtrusive Javascript are widely used for delivering alternate content to browsers.