Level: Introductory Edd Dumbill (edd@usefulinc.com), Chair, XTech Conference
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:
- HTML (now XHTML)
- XForms
- Web APIs
- Web Application Formats
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:
- XForms separate user interface presentation from data model
definition.
- XForms can create and consume XML documents.
- XForms are device independent. For example, you can use the same form in a voice
browser and on a desktop browser.
- XForms allow validation and constraining of input before
submission.
- XForms allow multi-stage forms without the need for scripting.
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:
- An API for dealing with the browser
Window object
- DOM Level 3 Events and XPath specifications
- An API for timed events
- APIs for non-HTTP networking, such as XMPP or SIP
- An API for client-side persistent storage
- An API for drag and drop
- An API for monitoring downloads
- An API for uploading files
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:
- Use XML as much as possible: Where a language feature already
exists in XML, don't duplicate or reinvent it.
- Structure over presentation: Thanks to CSS stylesheets, you no longer need explicitly presentational tags in HTML.
- Make HTML easier to write: Remove some of the needless
idiosyncrasies of HTML.
- More accessibility, device independence: Make as few
assumptions as possible about the way a document will be
read.
- Improved internationalization.
- Better forms: Long overdue improvements are required!
- Reduce the need for scripting: Include typical scripting
usages in HTML itself.
- Better semantics: Make it easier to integrate HTML with
semantic Web applications.
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
<section> and <h> (heading)
elements:
<section>
<h>Level 1 heading</h>
...
<section>
<h>Level 2 heading</h>
...
</section>
</section> |
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 <img> 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 <img> 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:
<p><img src="http://example.com/water.png">H<sub>2</sub>O</img></p> |
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
<object> 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 <object> 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 <address> and <title>.
The problem with these is that they are few and not extensible. In
the meantime, some have attempted to use the class attribute to
give semantics to HTML elements. This is stretching the purpose of
class 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 class, but the latter point
is undeniable.)
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".
The about attribute acts like rdf:about,
specifying the subject of an RDF triple -- it can be missing,
in which case the document itself will the subject. The
property 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 Resources).
Finally, the third value in the triple is given by the content of
the element to which the about and
property attributes are applied -- or if it's empty, the
value of the content attribute. Here's a simple
usage that will be familiar from existing uses of the HTML
<meta> tag, specifying a creator in the page header:
<html xmlns="http://www.w3.org/2002/06/xhtml2/" xml:lang="en">
<head>
<title>Edd Dumbill's Home Page</title>
<meta property="dc:creator">Edd Dumbill</meta>
</head>
...
</html> |
Now look at this example given by Pemberton, which shows how to use metadata in the actual body of the document:
<h property="title">Welcome to my home page</h> |
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 <pre><code> ...
</code></pre>? Now you can use the new
<blockcode> 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 <h1> to
<h6> elements were carried through as a
compatibility measure, as was <img>.
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.
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.
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. |
Rate this page
| 
