Jul 252008
 

Eric Meyer has put together a proposal for HTML 5 to enable an HTML document to associate URL links with just about every visual HTML element type. This would make it much easier to make a blockquote link to the source of the quote, and would enable things that are currently impossible in HTML such as making an entire row of a table into a link.

The proposal outlines several possible avenues for extending HTML syntax and considers their repercussions for functionality and backwards compatibility. Most of the extension choices can be supported in older browsers using JavaScript to backfill support for the HTML attributes the browser doesn’t understand.

I like the idea of allowing any element, even large blocks, to have an optional link associated with it. This improves the scope of reference to more naturally reflect the semantic structure of the referring document. If you quote a whole paragraph from somewhere else, doesn’t it make more sense that the entire quote be a live link to the original source? The current HTML link patterns force you to inject awkward transition text into the article just so you can have something to hang a link off of. I find such callouts disruptive to the flow of narrative text. Callouts often give the reference too much visibility relative to the content around them – another distraction.

Decreasing the need for artificial link phrases could be a benefit and burden for search engines. Search engines typically place a lot of weight on what words are used in the reference to associate some keyword digest of what the referenced page is about. This is a key technique for finding images with text search queries. How does a search engine deduce that “DSC10034.jpg” is an image of a horse? By noting that three different pages link to it, and the text of the links contains the word “horse”.

A block quote or table row that references another document would likely overload the simple referring text search engine technique with too much data, so the link would not be as strong of a keyword signal as two or three word phrase calculated by a human semantic engine. On the other hand, human digests are notoriously bad. Mislabeling is extremely common on the web, either by ignorance, apathy, or malicious intent. (Somebody actually tagged my photo of an Adelie penguin as a “parrot”! Gah!)

Eric has a demo page showing how one of the HTML extension options might look like, and how JavaScript can backfill for browsers that don’t understand the extensions.

Keep in mind while tinkering with the demo that the proposal is about extending what information can be represented in HTML syntax – the proposal is not about how an HTML renderer would present that information on the screen. I absolutely not want entire blocks or table rows drawn with the traditional underscored text of a hyperlink.

Certainly, a page that uses links for blockquotes or table rows could define its own CSS style elements to make the linked element less obnoxious to the eye. I would hope for more subtle visual cues that let the reader know that the linked element has more information, more depth of content, available for drilldown without disrupting the flow of the eye across the page. I would also hope that browsers that support these HTML link extensions will consider these distinctions between a “hard” a link and a more subtle content drill-down link when setting their default rendering styles.

Discovered via Ajaxian

  One Response to “HTML 5 Linking Proposal: Depth for Every Element”

  1. I too would love to turn a table row into a link. Recently I had a project where I needed just that. I then tried my hand at some javascript. The tag of course has an OnClick event, like most elements.

    Which worked great, but then someone noticed that the keyboard navigation was broken. The users were unable to use the Tab key to reach the “link”.

    So I backtracked and added an element inside that row. Problem fixed!

    …or was it?

    If the user clicks outside the anchor, everything is fine. However, if he clicks on the anchor itself, the server receives two hits instead of one. One hit because of the row’s OnClick event, and an additional hit from the A element!

    d’Oh!

    Developing applications for the web strikes me as counter intuitive. We developers are left with fewer tools, more testing and the results are generally much worse than most traditional apps designed for the Windows platform.

Sorry, the comment form is closed at this time.