Category Archives: Web

Future web: XHTML 2


The current common recommendation is that websites be written in standards-compliant XHTML 1.1 and CSS 2 with optional Javascript 1.5 support. What’s next for the web?

The XTech conference generated a lot of buzz this past summer in the web-techie community. There were presentations on XHTML 2 and the so-called HTML 5, which are both extrapolations of current popular standards, from groups which are (sort-of) competing for mindshare. There were also talks by technologist trying to transcend HTML entirely: both Microsoft’s XAML and Mozilla’s XUL are XML-and-script models for rapid GUI application development.

I hope to talk about all of these eventually, but right now I’m interested in XHTML 2. This article will delve into a few of the more interesting changes that are proposed in that draft. For readers from the future (hi cool future people!), here’s a permalink to the latest XHTML 2 docs, which is thesame as the above as of this writing.


The main goal of XHTML 1.0 and 1.1 was to be as HTML-like as possible while enjoying the improved parsability of XML, which is stricter than HTML.

In contrast, XHTML 2 is a small evolutionary step away from HTML. The goals are to reduce the amount of presentation information encoded in the data (instead pushing presentation details to CSS), reducing the amount of scripting needed to accomplish common tasks, improving accessibility, and improving hooks for semantic content (that is, metadata).


HTML included h1, h2, .. h6 tags to mark headers along with p, span and div tags to mark sections. Unfortunately, the h1h6 and p tags have strong presentation meanings (titles and paragraphs) and therefore are harder than necessary to use for general blocks of text.

XHTML 2 generalizes this with the section and h tags. The section tags can nest (unlike p tags) so you no longer need to specify a header level for the h tag — it’s implied by the depth of the section. For example:

<!-- HTML -->
<p>Intro text...</p>
<h2>Chapter 1</h2>
<p> Chapter body </p>

<!-- XHTML 2 -->
  <h> Title </h>
  <p>Intro text...</p>
    <h> Chapter 1 </h>
    <p> Chapter body </p>

The gains from this slightly-more-verbose syntax include:

  1. The nested sections are much easier to parse for a non-human. It would be trivial to write a program to extract Chapter 1, for example.
  2. The header levels are now relative, so if you later demote Chapter 1 to a subsection, you don’t need to renumber the header tags.

XHTML 2 also changes the p tag a little bit to allow nested lists (like ul and ol) and the like, to make them more like the human concept of a paragraph as a small block of related idea than a page layout concept of a paragraph as text offset from other text by whitespace.


XHTML 2 offers a new blockcode tag for presenting computer source code verbatim., instead of the generic pre tag offered by HTML. This is a minor change, but it can be a big plus for search engines looking for code examples. In conjunction with metadata markup, an author could indicate the language of the source code. For example (this is probably bad syntax):

<blockcode xmlns:prog=""
                      property="prog:language" content="Perl5">
    sub hello {
        print "Hello, World!\n";
Semantic text

In HTML, the tt tag is commonly used for keyboard input, variable names, blocks of code and more. XHTML 2 adds or enhances a few tags to disambiguate those usages. Respective to the above list, one could use kbd, var and code tags.


XHTML 2 allows href attributes to be added to any tag instead of just to a tags. This allows you to link, say, a blockquote to the source of the quote, or to link an image without wrapping it in an a tag. In the case of the quote, it would be even better to use the new cite attribute. cite works just like href but makes it more clear that the specified URL is included as reference instead of as a recommended navigation point.

XHTML 2 also adds the hreflang to go along with href to let users know that the target may be in a different language. Along the same vein, the hreftype can specify the MIME type of the target, for example application/pdf. Since HTML lacks this latter attribute, authors often tell their users the target type in prose. For example <a href="foo.pdf">Foo</a> (PDF).


HTML coders are very familar with alt tags on images — that is displayed if the image is unavailable or if the user has a text-only browser. XHTML 2 generalizes that concept via the embedding concept. Consider this example from the XHTML 2 docs:

<p src="holiday.png" srctype="image/png">
    <span src="holiday.gif" srctype="image/gif">
        An image of us on holiday.

This means:

  1. Load and display holiday.png
  2. If that fails, load and display holiday.gif
  3. If that fails, display the text “An image of us on holiday.”

The src attribute can be applied to any tag. Consequently, the img tag is no longer special. This is like how a is no longer special since href attributes can be applied to any tag.


HTML coders are familiar with the media attribute on link tags that let you, say, write a CSS file that applies only to media="print. Now, media can be applied to any tag. For example:

<span src="photo.jpg" media="screen">Me at work</span>
<span src="photo-hires.jpg" media="print">Me at work</span>

Personally, I think this one may be a step backward since it entangles presentation and data. But it’s undeniably clever. Doing this stuff inline is easier than in a separate CSS file that has to declare display="none" or set a background image on some tag.


XHTML 2 has copious support for metadata. If you’re interested, I recommend just reading the Metainformation Module in the XHTML 2 specification. I’ll just share a few clever examples:

<link media="print" title="The manual in PostScript"
  rel="alternate" href=""/>

<meta property="dc:creator">Chris Dolan</meta>
<meta property="dc:created" datatype="xsd:date">2005-10-28</meta>
<link rel="author" href="" />

Note: the dc: prefix is a reference to the Dublin Core XML namespace.


XHTML 2 introduces “roles” to assist with accessibility. You can, for example, tag your search box as follows to make it easier for a user to get to it (note the form below is not quite real XHTML 2 syntax):

    <access key="s" title="Search" targetrole="search" />
    <form role="search" action="search.cgi">
      Search: <input type="text" name="q" />

There is a predefined, standard set of roles (like “search”) that any page can implement.

Forms and Scripting

XHTML 2 uses XForms, which is intended to be an improvement on HTML forms. I haven’t delved into this that much, but a key point seems to be separation of model from interface. Also, the new system allows for some standard filters that can be implemented without Javascript.

XHTML 2 also uses XML Events. This generalizes the Javascript-specific event notation (think onclick="JS code...") to support any event in any language. You can optionally specify listeners to events separately from the tags that generate those events.

A major gain from the XML Events change is that the mutually-incompatible Netscape and IE event handling models are discarded in favor of a standard model. Yay!

The script tag is now called handler and is intended to support any language that the user agent can support. (Want to code your XHTML page in Perl or Python?)

An unrelated note on scripting: document.write doesn’t work. Instead, you have to add nodes via the XML DOM API. When it comes to limiting the problem of script injection and cross-site scripting attacks, this is a good thing.

Unicode development under Apache

One of my current projects is to port an application to Japanese. The first port is always the hardest1, so I’ve learned a few things in the process. I’m going to accumulate a few of my successes in this blog category. The first and most significant is that the way encodings work in HTTP/HTML is weird!

Take a peek at this slide from a talk by Sam Ruby, which shows an example HTML page with conflicting metadata. When there are conflicting directives indicating which encoding to use for the document, can you guess which one wins? You may be surprised to learn that the encoding specified in the HTTP Content-Type has precedence over the encoding declared in the HTML file! That is to say, if your HTML document claims

    <meta http-equiv="Content-Type"
              content="text/html; charset=Shift-JIS" />

and Apache says

    Content-Type: text/html; charset=ISO-8859-1

then Apache wins and your Japanese page will be rendered as Latin-1 in the browser and will likely be garbled. Apache’s out of the box configuration often includes a default encoding2 which may or may not be right.

There are two solutions to this problem:

  1. Make Apache ignore encoding
  2. Use exactly one encoding everywhere and always

The latter is good practice, but the former is easier. To make Apache ignore encoding, search your httpd.conf file for any AddDefaultCharset lines and removing them.

In our project, we chose the other route, making the obvious choice to use UTF-8 everywhere. We added this line to Apache:

    AddDefaultCharset UTF-8

and these lines to all HTML and XHTML files, respectively:

    <meta http-equiv="Content-Type"
           content="text/html; charset=utf-8" >
    <meta http-equiv="Content-Type" 
           content="application/xhtml+xml; charset=utf-8" />

Then, the major remaining hurdle was to ensure that all of our development tools actually read and write UTF-8. That will be the subject of a future post.

1 I’ve found this to be universally true for language, hardware, OS, API and other types of porting.

2 Two data points:

  1. Our main webserver runs RedHat, whose Apache had AddDefaultCharset ISO-8859-1
  2. The default Apache configuration under Mac OS X does not include a default character set. Good job Apple!