The Missing <link> in the World Wide Web

One of the very foundations of the web in general is that it allows us to create links between different resources. Further — we need to do so in a meaningful and accessible way. Many developers are favouring semantic markup over presentational markup. Witness the two articles released at A List Apart on techniques (and caveats when using those techniques) for styling proper headings (<hn>) with stylesheets (see Facts and Opinion About Fahrner Image Replacement), and using unordered lists coupled with stylesheets for navigation (see Sliding Doors of CSS). Caveats and implementation problems aside, these techniques, specific articles and the fact that developers and others are willing and able to engage in discussion about the issues are testament to the fact that many developers do care about standards and accessibility.

The unsung hero of (X)HTML, and, in my opinion, perhaps the most underutilized element is the <link /> element. It confers meaning and establishes relationships between resources — exactly what we need to make our lives easier, as we strive towards a more meaningful, accessible web.

Overview

The link element is placed in the head of a document to help provide metadata and establish a relationship between an individual resource and the resources to which it is linked. Traditional uses of <link rel="" /> include linking to a stylesheet to be applied to a document, adding a P3P Privacy document to your site or providing a “favicon” graphic to User Agents. For example:


<link rel="stylesheet" type="text/css" href="/styles/main.css" media="screen"/>
<link rel="P3Pv1" href="/w3c/p3p.xml" />
<link rel="shortcut icon" href="/favicon.ico" />


Recently, <link rel="" /> has become more popular for establishing relationships between several documents in a series (i.e., which document comes next, or is previous, or is the home page, or contains a copyright statement), or to establish an "alternate" version such as an RDF/RSS Feed.

Autodiscovery

When we add the line <link rel="alternate" type="application/rss+xml" href="/feed/rss2"> to a site header we establish a relationship between the main web site, and its syndicated content. Many RSS Aggregators and Feed Readers”>feed readers such as FeedDemon allow for autodiscovery of news feeds. If you don’t know the exact location of the feed, you can simply enter the site URI and the feed reader will try to determine the location of the feed. Using <link rel="" /> establishes that relationship and allows for autodiscovery.

Alternative Media

When we deal with audio, video, complex or simple images, or other elements that we build into our web sites, we are encouraged to provide meaningful alternative content. Different techniques and usages exist including, but not limited to:

• alt text on images
• nesting a static image inside the object tag when using flash
• providing text transcripts of audio files, or other media

Providing these "alternate" versions are important for accessibility, however all of them suffer from some problem or another. As an example, a longdesc for an image is usually only available via a secondary mouse click, or via an obscure and not widely used d-link. Providing text transcripts requires the author building a link to the file somewhere in the flow of the page in order to make it available to the users.

Wouldn’t it be nice if we could simplify this process? Perhaps its not that there is a missing “link”, but rather a missing attribute.

Changing the spec

The HTML 4 Specification”>for attribute on the HTML 4 Specification”>label element (eg. <label for="foo" >FooLabel</label>) associates a label with the form control that has that particular id (i.e., <input type="text" id="foo" />).

So, why not change (X)HTML to allow the for attribute to be a valid attribute of the link element? Then we could theoretically associate any link element to another element in that document (or another document for that matter). For example:


<link rel="alternate" for="piechart1b" type="text/html" title="Detailed Usage Information by Country for June 2002 X" href="/longdesc/index.html#piechart1b" />

<link rel="alternate" for="speech1a" type="text/plain" title="Text Transcript" href="/transcripts/speech1a.txt" />


Which would correspond to the following elements in the body:

and

<img id="piechart1b" src="/images/pie1b.png" alt="Usage by Country for June 2002, pie chart format" />


This would essentially allow for user agents to "auto-discover" the alternate versions of different elements within a page, and in some way present links to them. The exact rendering/display would be dependent on the user agent — we could foresee a couple of scenarios:

1. A simple extension of the current functionality in Mozilla‘s Site Navigation bar or Opera’s Navigation Bar
2. Reading the User Agent preferences and presenting a physical link to the alternative version within the document. This could be automated if the User Agent is configured to do so, or simply because it is unable to show images or other multimedia items or files.
3. Presentation/inclusion within a links list much like screen readers and other assistive technology provide

Changing User Agents

There would definitely be some changes to user agents required in order to implement this, but I would suggest they are all for the better. With the on-again, off-again development of IE for Mac and PC, and IE being the biggest disappointment as far as lack of support for link rel goes, this might all just be a pipe dream. However, this could be a step in the right direction – both in terms of striving towards well structured documents with well-defined semantic relationships, and in terms of the way that users are able to interact with web resources through their user agents.

A way forward…

We already have the ability to override stylesheets within a web document, so why not be able to override multimedia settings as well? I could configure my UA to display text transcripts rather than audio files by default. Users of JAWS or other screen readers could configure their software to announce the title of the alternative resource as specified by the <link rel="" title="" /> as they encounter their associated elements in the page.

This would also allow for much enhanced content management. When multiple versions of a "resource" exist within a Content Management System, the appropriate number of <link rel="" /> elements could be added to the head of the HTML document. Consider the following alternatives for a complex Flash animation:


<link rel="alternate" for="foo" type="text/plain" title="Text Description of Animation" href="/text/foo.txt" />

Other Uses

If we were able to use this mechanism to bind alternate resources to any item on the page using <link rel="Alternate" />, why not use the same mechanism for other HTML 4 Specification”>predefined link relationships for the link element? How about using:


<link rel="Help" for="firstname" href="/help/firstname.html" />

This would create easily accessible help for form controls contained within the document and allow user agents the ability automatically discover and link to it. Screen readers, for example might be automatically configured to read the help text for the item when the form control receives focus and the user is in "forms mode", or at the request of the user at any other time.

The real question then becomes can the spec change, and will the browsers change too? These may seem like quick changes, but in reality may not be possible. However, browser makers should consider incorporating these changes into their next build, and developers could then employ custom Document Type Definitions (DTDs) that would then allow for the <link /> element to be used in this fashion. This functionality is already allowed for in the HTML 4.01 spec Link types section.

It may not be too late to add the for attribute to the link element, despite the fact that the W3C are already working on XHTML 2.0. In XHTML 2.0, there is no <label /> element as it has been removed from XHTML and appears to be dealt with in XForms 1.0.

If it means a small change in the way that browsers use the <link /> element, and it will be a while before XHTML 2.0 and XForms 1.0 are mature enough for mainstream usage, then it might be possible to implement these changes quickly. If change is possible or the same ideas incorporated into XHTML 2.0, we might be on the way to a more meaningful and accessible web.