Friday, January 27, 2006

The future of HTML, Part 2: XHTML 2.0

25 Jan 2006

In this two-part series, Edd Dumbill examines the various ways forward for HTML that Web authors, browser developers, and standards bodies propose. This series covers the incremental approach embodied by the WHATWG specifications and the radical cleanup of XHTML proposed by the W3C. Additionally, the author gives an overview of the W3C's new Rich Client Activity. Here in Part 2, Edd focuses on the work in process at the W3C to specify the future of Web markup.

In the previous article in this series, I described why HTML is due for an update, both to fix past problems and to meet the growing requirements of the tasks to which Web pages and applications are put. I explained the work of the Web Hypertext Application Technology Working Group (WHATWG), a loose collaboration of browser vendors, in creating their Web Applications 1.0 and Web Forms 2.0 specifications.

In this article, I'll examine the work of the World Wide Web Consortium (W3C) in creating the next-generation version of their XHTML specification, and also their response to the demand for "rich client" behavior exemplified by Ajax applications.

The W3C has four Working Groups that are creating specifications of particular interest:

You can find links to each of these in Resources. This article mainly focuses on the work of the the HTML Working Group, but it is worth discussing each of the others to give some context as to how their work will shape the future of the Web.

XForms

XForms are the W3C's successor to today's HTML forms. They are designed to have richer functionality, and pass their results as an XML document to the processing application. XForms are modularized, so you can use them in any context, not just attached to XML. XForms' key differences from HTML forms are:

As it is a modularized language, XHTML 2.0 imports XForms as a module for its forms functionality.

Web APIs

The W3C's Web APIs Working Group is charged with specifying standard APIs for client-side Web application development. The first and most familiar among these is the XMLHttpRequest functionality at the core of Ajax (which is also a technology that the WHATWG has described). These APIs will be available to programmers through ECMAScript and any other languages supported by a browser environment.

Additional APIs being specified are likely to include:

While these APIs do not need to be implemented in tandem with XHTML 2.0, browsers four years in the future will likely integrate them both to provide a rich platform for Web applications.

Web Application Formats

XHTML 2.0 is one part of the Web application user interface question, but not the totality. Technologies such as Mozilla's XUL and Microsoft's XAML have pushed toward a rich XML vocabulary for user interfaces.

The Web Application Formats Working Group is charged with the development of a declarative format for specifying user interfaces, in the manner of XUL or XAML, as well as the development of XBL2, a declarative language that provides a binding between custom markup and existing technologies. XBL2 essentially gives programmers a way to write new widgets for Web applications.

Why XHTML 2.0?

The purpose of XHTML 1.0 was to transition HTML into an XML vocabulary. It introduced the constraints of XML syntax into HTML: case-sensitivity, compulsory quoted attribute values, and balanced tags. That done, XHTML 2.0 seeks to address the problems of HTML as a language for marking up Web pages.

In his presentation at the XTech 2005 conference in Amsterdam (see Resources), the W3C's Steven Pemberton expressed the design aims of XHTML 2.0:

These aims certainly appear pretty laudable to anybody who has worked with HTML for a while. I'll now take a deeper look at some ways in which they were achieved in XHTML 2.0.

Sections and paragraphs

When I was a newcomer to HTML many years ago, I remember experiencing a certain amount of bemusement at the textual structural elements in the language. Why were there six levels of heading, and when was it appropriate to use each of them? Also, why didn't the headings somehow contain the sections they denoted? XHTML 2.0 has an answer to this, with the new

and (heading) elements:


Level 1 heading
...

  Level 2 heading
  ...


This is a much more logical arrangement than in XHTML 1.0, and will be familiar to users of many other markup vocabularies. One big advantage for programmers is that they can include sections of content in a document without the need to renumber heading levels.

You can then use CSS styling for these headings. While it is to be expected that browsers' default implementations of XHTML 2.0 will have predefined some of these, written explicitly they might look like this (abstracted from the XHTML 2.0 specification):

h {font-family: sans-serif; font-weight: bold; font-size: 200%}
section h {font-size: 150%} /* A second-level heading */
section section h {font-size: 120%} /* A third-level heading */

Another logical anomaly in XHTML 1.0 is that you must close a paragraph in order to use a list. In fact, you must close it to use any block-level element (blockquotes, preformatted sections, tables, etc.). This is often an illogical thing to do when such content can justly be used as part of the same paragraph flow. XHTML 2.0 removes this restriction. The only thing you can't do is put one paragraph inside another.

Images

The tag in HTML is actually pretty inflexible. As Pemberton points out, it does not include any fallback mechanism except alt text (hindering adoption of new image formats), the alt text can't be marked up, and the longdesc attribute never caught on due to its awkwardness. (longdesc is used to give a URI that points to a fuller description of the image than given in the alt attribute.)

XHTML 2.0 introduces an elegant solution to this problem: Allow any element to have a src attribute. A browser will then replace the element's content with that of the content at the URI. In the simple case, this is an image. But nothing says it can't be SVG, XHTML, or any other content type that the browser is able to render.

The tag itself remains, but now can contain content. The new operation of the src attribute means that the alt text is now the element's content, such as in this example markup:

H2O

This is especially good news for languages such as Japanese, whose Ruby annotations (see Resources) require inline markup that was previously impossible in attribute values.

XHTML 2.0 offers a more generic form of image inclusion in the element, which you can use to include any kind of object -- from images and movies to executable code like Flash or Java technology. This allows for a neat technique to handle graceful degradation according to browser capability; you can embed multiple elements inside each other. For instance, you might have a Flash movie at the outermost layer, an AVI video file inside that, a static image inside that, and finally a piece of text content at the center of the nested objects. See the XHTML Object Module (linked in Resources) for more information.

Extensible semantics

HTML has long had some elements with semantic associations, such as

and </code>. The problem with these is that they are few and not extensible. In the meantime, some have attempted to use the <code>class</code> attribute to give semantics to HTML elements. This is stretching the purpose of <code>class</code> further than it was designed for, and can't be applied very cleanly due to the predominant use of the attribute for applying CSS styling. (Some argue about this assertion of the purpose of <code>class</code>, but the latter point is undeniable.) </p> <p>Moving beyond these ad-hoc methods, XHTML 2.0 introduces a method for the specification of RDF-like metadata within a document. RDF statements are made up of triples (subject, property, object). For instance, in English you might have the triple: "my car", "is painted", "red".</p> <p> The <code>about</code> attribute acts like <code>rdf:about</code>, specifying the <i>subject</i> of an RDF triple -- it can be missing, in which case the document itself will the subject. The <code>property</code> attribute is the URI of the property referred to (which can use a namespace abbreviation given a suitable declaration of the prefix; more detail is available in the XHTML 2.0 Metainformation Attributes Module, see <a href="http://not-a-real-namespace/http://www-128.ibm.com/developerworks/xml/library/x-futhtml2.html?ca=dgr-lnxw01XHTML2#resources">Resources</a>).</p> <p>Finally, the third value in the triple is given by the content of the element to which the <code>about</code> and <code>property</code> attributes are applied -- or if it's empty, the value of the <code>content</code> attribute. Here's a simple usage that will be familiar from existing uses of the HTML <code><meta></code> tag, specifying a creator in the page header:</p> <table bgcolor="#eeeeee" border="1" cellpadding="5" cellspacing="0" width="100%"><tbody><tr><td><pre><code class="section"><html xmlns="http://www.w3.org/2002/06/xhtml2/" lang="en"><br /> <head><br /> <title>Edd Dumbill's Home Page
Edd Dumbill

...

Now look at this example given by Pemberton, which shows how to use metadata in the actual body of the document:

Welcome to my home page

This denotes the heading as the XHTML 2.0 title of the document, and specifies it as the inline heading. Finally, an end to writing the title out twice in every document!

Thanks to a simple transforming technology called GRDDL (Gleaning Resource Descriptions from Dialects of Languages -- see Resources), you now have a single standard for extracting RDF metadata from XHTML 2.0 documents.

XHTML 2.0 has plenty of other changes, many of which are linked in with the parallel development of specifications such as XForms. I don't have room to cover them all here. Regardless, it's certainly a marked leap from XHTML 1.0.

A few other new toys in XHTML 2.0

Fed up with of writing 

 ...
? Now you can use the new element.

To help with accessibility requirements, XHTML 2.0 now has a role attribute, which can be specified on any body element. For instance, purely navigational elements in the page can have a role="navigation" so text-to-speech engines can process it intelligently.

Browsers currently support some navigation of focus through the Tab key, but it can be arbitrary. The new nextfocus and prevfocus attributes allow you to control the order in which focus moves among the screen elements; this can be a vital feature for creating navigable user interfaces.

Preparing for XHTML 2.0

However deep the changes in advanced features, XHTML 2.0 is still recognisably HTML. Although it has new elements, a lot of XHTML 2.0 will work as-is. The

to

elements were carried through as a compatibility measure, as was .

However, the mission of XHTML 2.0 was not to preserve strict syntactic backwards compatibility, so HTML renderers in today's browsers won't be able to cope with the full expressivity of XHTML 2.0 documents. Nevertheless, most Web browsers today do a good job of rendering arbitrary XML-plus-CSS, and a lot of XHTML 2.0 can be rendered in this way -- even though you won't get the semantic enhancements.

Some of the differences in XHTML 2.0 are very significant -- the transition to XForms being one the most notable, as well as the complete break from the non-XML heritage of HTML. So, you can't switch your sites over to serving XHTML 2.0 right now, but you can make preparations for the future:

  • Get serious about using CSS, and try to remove all presentational markup.
  • Think about how you can deploy microformats in your pages. Microformats allow you to present metadata in your HTML using existing standards (see Resources).
  • If you've not done so already, get experience with XHTML 1.0. Serving XHTML 1.0 pages today as if they were regular HTML is possible if they are crafted according to the XHTML 1.0 HTML Compatibility Guidelines, but can create complications. XHTML 2.0 can't be served in this way. For more on this, see Resources.
  • Experiment with the X-Smiles browser (see Resources), which offers XHTML 2.0 support, along with SVG, XForms, and SMIL 2.0 Basic capabilities.
  • If you create new client systems based on XHTML-like functionality, seriously consider using XHTML 2.0 as your starting point.

Finally, note that XHTML 2.0 is not a finalized specification. At the time of this writing, it is still in the Working Draft stage at the W3C, which means it has some way to go yet before it becomes a Recommendation. Importantly, it must still go through the Candidate Recommendation phase, which is used to gather implementation experience.

XHTML 2.0 is not likely to become a W3C Recommendation until 2007, according to W3C HTML Working Group Roadmap. This means that 2006 will be a year to gain important deployment experience.

Comparing W3C XHTML 2.0 with WHATWG HTML 5

In these two articles, I've presented the salient points of both WHATWG's HTML 5 and the W3C's XHTML 2.0. The two initiatives are quite different: The grassroots-organised WHATWG aims for a gently incremental enhancement of HTML 4 and XHTML 1.0, whereas the consortium-sponsored XHTML 2.0 is a comprehensive refactoring of the HTML language.

While different, the two approaches are not incompatible. Some of the lower-hanging fruit from the WHATWG specifications is already finding implementation in browsers, and some of WHATWG's work is a description of de facto extensions to HTML. Significant portions of this, such as XMLHttpRequest, will find its way into the W3C's Rich Client Activity specifications. WHATWG also acts as a useful catalyst in the Web standards world.

Looking further out, the XHTML 2.0 approach offers a cleaned-up vocabulary for the Web where modular processing of XML, CSS, and ECMAScript is rapidly becoming the norm. Embedded devices such as phones and digital TVs have no need to support the Web's legacy of messy HTML, and are free to take unburdened advantage of XHTML 2.0 as a pure XML vocabulary. Additionally, the new features for accessibility and internationalization make XHTML 2.0 the first XML document vocabulary that one can reasonably describe as universal, and thus a sound and economic starting point for many markup-based endeavors.

As with its past, the future of HTML will be varied -- some might say messy -- but I believe XHTML 2.0 will ultimately receive widespread acceptance and adoption. If it were the only XML vocabulary on the Web, there might be some question, but as browsers gear up to deal with SVG, XForms, and other technologies, XHTML 2.0 starts to look like just another one of those XML-based vocabularies.



Back to top


Resources

Learn

Get products and technologies
  • Take a look at the X-Smiles browser, an experimental platform with early (and sometimes only partial) support for many of the W3C's new client technologies, including XHTML 2.0, SVG, XForms, and SMIL.


Back to top


About the author


Edd Dumbill is chair of the XTech conference on Web and XML technologies, and is an established commentator and open source developer with Web and XML technologies



source:http://www-128.ibm.com/developerworks/xml/library/x-futhtml2.html?ca=dgr-lnxw01XHTML2


# posted by dark master : 1/27/2006 09:27:00 AM
Comments: Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?