XHTML 2.0: The Latest Trick
August 7, 2002
If the Semantic Web means anything, it means changing the Web's infrastructure just enough so that inter-machine exchanges become as ubiquitous, cheap, and easy as inter-human exchanges already are. One vital goal, however, is to make inter-machine exchanges possible without doing permanent damage to the ecology of the Web: inter-machine exchanges are not meant to replace or supplant inter-human ones, merely to supplement them. And a supplement, by its very nature, is always something one can do without. At present the primary medium of inter-human exchange on the Web is HTML. In the rush to tweak the Web's infrastructure to support inter-machine exchanges, we would do well to not forget about the importance of HTML among our grand semantic schemes.
The problem with inter-machine exchanges is that they are significantly more difficult to conceptualize, design, develop, and deploy than HTML-based web publishing. Therefore they are likely to be a supplement to the existing Web: most people won't actively develop or deploy mechanisms to facilitate them, but many, perhaps most Web users will benefit directly or indirectly from them.
In some ways, then, the Semantic Web will reverse the early Web's balance between producers and consumers. HTML was and is simple enough that just about anyone could learn enough of it to publish on the Web. And that was and is a very good thing. It is one of the things which the Semantic Web must never disturb. Some form of HTML, preferably XHTML, will always be the most ubiquitous type of Web content; people will keep writing it by hand, building user interfaces with it, trying, succeeding, failing to scrape useful information from it by means of machine processing, and so on. Any part of the Web's infrastructure with such a long future shelf life deserves careful and attentive shepherding.
It's this context, the long view of the Web's future and the way most people use it now and then, in which it makes the most sense to think about the first public draft of XHTML 2.0, which appeared on 5 August. Since HTML is going to be around for a very long time, it makes sense to rationalize it, continue evolving it, and, in general, to make it more powerful and more amenable to the kinds of things people want to do with it. There are signs, encouraging in such an early draft, that the W3C Working Group responsible for XHTML 2.0 understands and is working to enact this ideal.
The More Things Change, the More They Change
In what remains, I want to run down a list of noteworthy changes that have appeared in XHTML 2.0, considering how they are likely to impact a specific, but important, use case: people writing documents by hand to publish on the Web. The XHTML 2.0 draft doesn't enumerate all the changes from XHTML 1.1, so the following list is incomplete.
Navigation lists. One thing web designers have been doing forever is building ad hoc widgets, structures, scripts to display site navigation elements. In response to this universal need, XHTML 2.0 includes a new kind of list, represented by the element nl. Nav lists are, as the XHTML 2.0 draft states, "intended to be used to define collections of selectable items for presentation" in some kind of display structure, likely to be device and browser specific. The draft specifies a fairly abstract, default presentational rendering of nav lists for devices with a visual display, but leaves non-visual device rendering unspecified, wisely. In an XHTML 2.0 document, a nav list might look something like:
<nl>
<name>The Constitution of Mars </name>
<li href="#legislative">Article 1. Legislative Department</li>
<li>
<nl>
<name>Article 2. Executive Department</name>
<li href="#ec">Section 1: Executive Council</li>
<li href="#powers">Section 2: Powers of the Executive
Council</li>
</nl>
</li>
<li href="#judicial">Article 3. Judicial Department</li>
<li href="#governance">Article 4. The Global Government
and the Towns and Settlements</li>
...
</nl>
Adding the nav list to XHTML 2.0 has a kind of democratizing effect: people with little or no understanding of scripting or document object models will be able to write and deploy complex site and document navigational structures in a very simple way; and, it should be added, in a way that is a natural and organic extension of what they likely already know.
Everything is a link. XHTML 2.0 includes a group of element attributes which are defined for every element, called the "Common Attribute Collection" (CAC). Since attribute collections are often used to manage large XML or SGML applications, XHTML 2.0's CAC isn't noteworthy per se. However, XHTML 2.0 moves the href attribute into the CAC, which means that every element in XHTML 2.0 can be a hyperlink. That's the sort of fundamental change that it's hard to evaluate at this very early point, but it's immediate utility is pretty obvious. Instead of writing constructs like,
<h2> <a href="#rights">Article 5. Individual Rights and Obligations</a> </h2>
people will be able to write shorter, equally clear constructs like,
<h2 href="#rights">Article 5. Individual Rights and Obligations</h2>
I think this change will be very popular in the long run; but there are already those who've objected that XHTML 2.0 really should make some use of XLink (See Bob DuCharme's recent XML.com article, XLink: Who Cares?).
Unordered sections and headings. No other HTML bugaboo is more common than the total disaster which is numbered headings, intended to be the major structural elements of HTML documents, but which have been most often (mis)used for their conventional presentational effect. XHTML 2.0 does not yet deprecate the familiar set of h1 through h6 heading elements, though I think there's a pretty good chance that they will be deprecated eventually. XHTML 2.0 does, however, lay the ground work for their deprecation by adding section and h elements. The conceptual problem with h1-h6 headers has always been that they aren't container elements; they don't create a section, merely announce the change of section by some special rendering of the section's title. But document sections or segments are often explicitly construed as named or unnamed containers in other XML or SGML applications. With XHTML 2.0, document authors will be able to replace
<h2>Article 6. The Land.</h2> <h3>Section 1. Terraforming Goals and Limits</h3>
with the more verbose but more expressive (because, in part, fully nestable)
<section>
<p>...</p>
<h>Article 6. The Land</h>
<section>
<h>Section 1. Terraforming Goals and Limits</h>
<ol>
<li>The primal state of Mars shall have legal
consideration...
</li>
...
</ol>
</section>
</section>
This would allow, as in DocBook, for example, authors to have the flexibilty to commence a new section before announcing it; that is, the first element of a section no longer has to be its header, as in all variants of HTML to date.
Line breaks. Another point of tension between the various factions of HTML users has been the meaning and use of the br element; speaking stereotypically, designers have typically used it to force a particular rendering, while SGML and XML geeks have insisted that it should not be used in that way. The XHTML 2.0 draft seems to cut this gordian knot by simply deprecating br altogether. I say good riddance.
In the place of br, XHTML 2.0 offers line, which presently suffers from a bit of specification doggerel: "The line element represents a sub-paragraph" -- I've never met a sub-paragraph, and I'm not sure I'd be very happy if I did. What the draft means is that line can be used within a p element to indicate some constitutive part of a paragraph which should be rendered as starting on a new line and having a line break at its end.
Object über alles. img and applet are deprecated in favor of a object, which takes on a multivalent role as a kind of catch all, out-of-band media type entity. In other words, object in XHTML 2.0 is rather complex, and I haven't yet sorted out all that it can do. It is clear, however, that people won't be writing the familiar
<img src="/pix/pavonis-mons.gif"
alt="Approaching Pavonis Mons By Balloon" />
anymore. In its place, we'll use something like
<object data="/pix/pavonis-mons.gif" type="image/gif"> Approaching Pavonis Mons By Balloon </object>
At this point the type attribute seems to be optional, though it will be useful since it will give browsers some typing information with which it might make intelligent decisions about which version of an object it wants to retrieve or display.
Citing. Few HTML elements cause as much confusion or are as misused -- often by XML and SGML geeks who ought to know better -- as q and cite. XHTML 2.0 replaces q with quote, and leaves it to the author to add the appropriate inline quotation marks. cite in particular is widely thought to be a kind of synonym of blockquote, no doubt in part because of its unfortunate and misleading name. cite is supposed to markup citations: say, the title of a book from which one has quoted or to which one might refer. For instance, I have in this article been quoting from Kim Stanley Robinson's excellent little book, <cite>The Martians</cite>. XHTML 2.0 retains cite as an element and as an attribute, which has a URI as its value, and adds the cite attribute to quote. I like the use of cite as an attribute holding a URI; it's one of those stress points at which the variegated folds of Semantic and the Human Webs intersect:
<p>Robinson understood the importance of civic involvement, enshrining it in the constitution of his fictional Mars: <quote lang="en/us" cite="http://ks-robinson.info/MarsConstitution/Article5/ Section2/Part1">The citizens of Mars shall, over the course of their lives, give one m-year of work to global service and the public good, such work to be defined by the economic commission, but never to be military or police work.</quote></p>
|
|
|
Also in XML-Deviant |
|
It's not yet clear to me on which elements cite as an attribute is available in XHTML 2.0, but I would like to see it very widely available, perhaps joining href in the CAC. It simply cannot hurt for there to be more links in a global hypertext system, particularly typed links, and ones which offer both humans and machines other nodes on the Web at which related information may be obtained. One fly in this bit of soup, however, is the further conspicuous absence of XLink, which seems applicable to the kind of concern cite addresses.
It's clear that XHTML 2.0, despite its warts and omissions, which are by no means critically problematic at such an early stage, is a gesture in the right direction, that it gets more right than wrong. I suggest that the Working Group take its time with XHTML 2.0; given the slow adoption of XHTML 1.1, version 2.0 is not going to be used en masse anytime soon. There's no need to rush. I just hope we have browsers supporting XHTML 2.0 before someone actually needs to put a real Mars Constitution on the Web.