Linking in XHTML 2.0

How XHTML 2.0 is Changing the Way People Think About Web Linking

As a fundamental part of the Web, hypertext linking has been the subject of repeated attempts at standardization beyond the basic format allowed in simple HTML. Such attempts can be characterized as efforts to balance machine processing ability with authoring convenience. The latest specification in this area, XHTML 2.0, just might have gotten it right.

The one thing basically all Web sites have in common is hyperlinks. Beginning and advanced Web surfers alike rely on links to navigate around the Web. From the earliest days of XML, the standards-builders always considered linking an essential part of their overall story arc -- in fact, the linking specification was once called "Extensible Markup Language (XML): Part 2. Linking" (see Resources).

Web authors are familiar with simple linking markup like that in Listing 1, where href attributes create links that the user can choose to follow, and src attributes create links that usually load automatically.

Listing 1. HTML linking

XHTML version 2.0 preserves the basic approach here, but adds a new twist. The following information is based on the XHTML 2.0 Working Draft of 22 July 2004.

Linking: From Any Element

Listing 1 uses the a element -- which stands for an "anchor" -- to define an outgoing link. Most people, however, think about anchors as link targets, not sources. Only by historical accident has the a element come to be the de facto way to specify links. In other words, there?s no good reason why other elements shouldn't also be able to serve as link ends. XHTML 2.0 dispenses with this limitation and broadly allows href along with several other attributes.

A table cell, an image, a list item -- anything can be a link. Just add an href attribute and put the destination URL as the value. In fact, one of the several attribute collections defined by XHTML 2.0 is the Hypertext attribute collection, which applies to every element in XHTML 2.0.

Why not XLink?
The W3C has a Recommendation called XML Linking Language (XLink -- see Resources) intended to be used for hypertext linking. However, XHTML in any version has been deemed incompatible with XLink. Still, XHTML has adopted the useful terminology and semantics defined in that specification.

XLink helps specify when a link activation occurs, including onLoad for typical images on a Web page, and onRequest for manually-activated hyperlinks. XLink also helps specify link behavior, including replace for hyperlinks that replace the current page, new for pop-up windows, and embed for things like images. XLink contains additional wording to ensure that these concepts can apply to contexts beyond basic visual browsers, including voice and accessibility applications.

So, what is incompatible about XLink? Much has been written about this (for a sampling, see Resources), but in short XLink expects all links to be named xlink:href, with the prefix mapped to a namespace in the usual fashion. As you will see in this article, XHTML 2.0 requires different kinds of links with different names, often on the same element.

The Hypertext Attribute Collection

Besides href, XHTML 2.0 supplies a collection of additional attributes to further augment the description of a link. These attributes, which are likely to change slightly by the time XHTML 2.0 reaches Last Call, are available in all the same places that href can be used:

• hreflang indicates the expected language at the remote end of the link. It may be a space-separated list.
• hreftype indicates the media type of the link destination; whether it is, say, SVG or XHTML or some other type. It too may be a space-separated list.
• cite designates a source document reference for some text, typically some kind of a quotation. Previously, this attribute existed only on elements like blockquote. Now that it is widely available, authors are thinking about richer ways to interconnect their hypertext. The interesting part is that the XHTML specification says that user agents "should" make this link available somehow. The details are left to each piece of software, but I'd expect to see this kind of link show up on a right-click menu in more-innovative browsers.
• access (which is quite different from accesskey in previous versions) assigns short names, like "contents", to various parts of a document. Accessibility tools can then handle those parts appropriately.
• The nextfocus and prevfocus attributes contain IDREFs of other elements. Taken as a whole, these form chains that guide navigation through the document, and they work for more than just anchors and form controls. The default navigation order is the same as the order in which the elements appear in the document; these attributes allow fine-tuning of navigation order. Additionally, if the XHTML document reference includes a fragment -- say http://search.example.com#query -- and the document includes a focusable element with an id of query, that element receives initial focus and serves as the starting point for further navigation.
• target and xml:base are largely unchanged in XHTML 2.0. Web authors might be accustomed to specifying target="_new" to specify that a link opens in a new window. XHTML 2.0 no longer hard-codes any special values, and instead defers to a related specification called XFrames (see Resources) to define how linked-to resources fit into the overall environment. The xml:base attribute sets up a context in which relative URLs are interpreted.

One good use for the Hypertext attribute collection is with navigation lists, a new feature in XHTML 2.0. Listing 2 illustrates:

Listing 2. Navigation list

Navigation lists help authors direct users through their Web sites, something that many developers have tried to accomplish through forms. However, the explicit hyperlink markup is a more natural -- and more accessible -- fit for conveying navigation information.

HLink: An alternate solution?
In response to apparent shortcomings of XLink, the HTML Working Group drafted a proposal called HLink (see Resources), which leveraged the good work in XLink in a way that could be mapped to arbitrary attributes on any element. HLink had some interesting additions, like a new actuate value of onRequestSecondary for right-mouse clicks or the equivalent, and ways to handle things like form submission and error handling that weren't clear with XLink by itself.

In the end, though, HLink wasn't an appropriate solution. The terminology and semantics from XLink could be used directly, without the need for a separate layer in between.