It's taken a while, but by now, 4 years after I originally published this paper, users can have LINK support on every major platform. We've come a long way. There now even is a LINK Toolbar for the Windows version of Explorer. (This is a third-party tool. I don't use Windows myself, so I have no idea how well it works. Give it a try and let me know.) Hopefully also Apple's very promising new web browser, Safari, will grow LINK support.

It's a maze out there

Ask any WWW newbie; ask any experienced Web surfer; ask any Web site developer "what are the biggest problems with Web sites?" and chances are "navigation" will rank in their top 3.

People get lost. Before they realise it, they're ten Web sites away from where they thought they were. Or they're in one section of a Web site looking for something in vain because it is actually in another section of the site.

As a result, visitors often are not only 'lost in cyberspace', they're also 'lost' to the owner of the Web site. Either simply because the visitor can't find his way back to the site, or because they give up in frustration. They might try elsewhere. Or they might give up their search completely.

Creating a Web site that is easy to navigate is one of the hardest things. The bigger the site, the sooner visitors will become confused about where they are. The reason for that, I believe, is twofold:

1. Every Web site looks and navigates differently.

   If you would compare Web sites' navigation systems with traffic signs, the problem with this is easily explained: although traffic signs aren't globally universal, at least on a national level they mostly are. If you know the sign, you will recognise it in every street and every city it is used in. Just imagine if every city, neighbourhood, or even every street would be using its own unique system of traffic signs. People would be at a loss all the time.

   Yet on the Web, this is reality. On the Web, people need to get used to each and every Web site's unique navigational system.
   

2. A Web site's structure can't be seen. It cannot be touched. It is abstract. Even to the author of the Web site this often is hard to deal with. Imagine how hard it must be for a visitor who doesn't know yet what a Web site contains nor how it is structured.
   

Current attempts

In order to ease a Web site's navigation, authors try all kinds of things. Like making every page 'look' the same, so at least visitors will (hopefully) recognise it when they followed an outside link. Authors may offer the user a 'site-map'. Many authors choose to use FRAMES (ignoring the problems many browsers have with FRAMES - ever tried bookmarking a set of frames?).

Some sites try to use signs/icons that are hoped to be understood more or less universally. We've all seen icons showing a house to indicate a link to a site's homepage for instance. However, most Web authors are either 'techies', or 'graphic designers', both of whom are often tempted to forget that iconography is a specialty in itself. As a result, many of the icons you encounter aren't very useful at best, or utterly confusing at worst. In part, that's because most Web publishers aren't iconographers. In part it is because Web publishers tend to insist on making their site look unique.

And although it makes sense to present your content in a unique way, both to support the uniqueness of your content and to stand out inbetween potential competitors, if you've read the previous section you've learned that that same uniqueness is what causes navigational problems.

Future solutions

Wouldn't it be great if the Web would have some form of universal 'traffic signs'? A scheme that would allow visitors to easily and quickly navigate through Web sites. Wouldn't it be great if browsers would have some kind of build-in sensor, that would be able to tell visitors where to find the homepage to a site, where to find an index, where to find a help page, or a search page? No matter what Web site is being visited? A system capable of visualising a Web site's structure. A system where, no matter how deep a visitor has travelled inside a Web site, he can still find his way without a blink.

And wouldn't it be great if such a system would not stand in the way of a Web site's unique presentation of content? Surely that would be the best of both worlds: to have both universally understood navigation and unique presentation of content at the same time.

Introducing: <LINK>

Well, have I got news for you: there is such a system. And it has been around for quite a while now. The HTML 2.0 standard, which dates back to November 1995, already included the LINK element.

The LINK element offers WWW authors a way to define a few 'standard links' - links to the kind of places that most Web site's structures use, such as a homepage, a help page, the next or previous page, the parent document, a page offering contact information, etc. Almost every Web site uses at least some of those pages. And they're usually the most essential pages.

Surprised? You ask yourself, if there was a solution all this time, why have I never encountered it?. Well, one of the reasons you may have not seen this yet is because most Web authors don't use it. And probably one of the main reasons they don't use it is that most Web browsers don't support it. Yet.

Up untill recently, the only Web browser (that I know of) that supports the LINK element was Lynx. Below is a snapshot of how a page that makes use of LINK may look in Lynx.

I bet you're not impressed. Sure, obviously the LINK element makes navigation much easier, but Lynx is a text-based browser and as such can handle only text for in-line presentation. (Lynx can handle other content, such as images, movies, etc., very well - just not in-line.)

So what we really want is a 'graphical' browser that supports LINK. Well, there is no reason why that should be a problem. All browser vendors need to do is add support for it. Considering all the great gizmos they've been able to toss at us in the past few years, it can't be hard for them to add support for something as simple and straightforward as LINK.

In fact, a little while ago, a 'graphical' browser that does support LINK entered the WWW stage. And it does this very well. This browser's name is iCab and it's a remarkable piece of beauty. It leaves 'The BIG 2' far behind in many areas. Even though iCab is still in development and the versions that are currently available are considered "previews", I could write a book about how iCab gave me back the fun of surfing the Web. But I won't do that now and here. For now we'll stick with the issue at hand: Navigating the WWW, and the LINK element.

So what does LINK look like? Well, like all HTML, that depends on the Web browser (and the user's settings of it). And that's very much the point of it! Because the browser decides how to convey a LINK element's meaning to its user, it can convey that information in a consistent manner - much like the "back"-button, which always looks the same, no matter what Web site is being visited (stupid javascript authoring attempts aside).

Here's how iCab displays the LINK elements (in a tiny "Special Links toolbar", just below the URL field, taking up far less screen space than your average navigation frame does):

For a LINK element that isn't specified, iCab will 'gray-out' the icon to protect the user from selecting an option that's not available.

From left to right, these icons represent the following LINK elements:

1. home, start, top
2. contents, TOC
3. begin, first
4. prev, previous
5. next
6. end, last
7. up
8. index
9. find, search
10. help
11. copyright
12. author, made
13. The upside-down pyramid is a special case and works threefold (as shown in the image below):
    1. it shows the content of the TITLE attributes of the 12 above mentioned LINK elements, as well as of any additional LINK elements
    2. the individual items can of course be selected and thus function the same way as the icons do, but with a more specific clue about where it will take you
    3. At the bottom of this menu iCab will display the names of any linked Style Sheets. Selecting those will make iCab load and display the CSS code. (Note that this last bit is nothing more than a description of current behaviour in iCab. iCab, as of yet, doesn't have support for CSS. When it does, this item in the menu may be used differently - perhaps to allow users to select different Style Sheets. Only the author knows.) iCab 3, which has added excellent CSS support, does not list Style Sheets here anymore.

I can hear you say: "Yeah, well... cool. But iCab is Mac OS-only". That is true. But 2 other things are also true:

1. Using LINK will help people who use LINK-capable browsers such as Mozilla, Firefox with its LINK toolbar installed, Opera, iCab, Lynx or WinIE with its LINK Toolbar installed, and it won't hurt users of other browsers.
   

2. By using iCab as an example and presenting its capabilities, not in yet another Mac-vs-PC advocacy or a 'which browser is best' debate, but in the much broader setting of the very real problem of WWW navigation, I'm hoping to encourage both Web publishers and browser vendors to start using LINK. Call me naive if you want, but I like to think that the more sites use LINK, the more browser vendors will be inclined to implement support for it.
   

Of course LINK is not a complete solution for every conceivable situation. Don't mistake LINK for the Holy Grail of WWW navigation. Individual Web sites may need to offer visitors additional clues. But using LINK can help a lot. And perhaps there are possibilities of even extending the current definition of LINK in the future.

• Michael Nahrath has assembled just about all relevant documentation and discussion concerning the LINK element at "The 'link'-Element in (X)HTML".
• Matthias Gutfeldt has managed to collect information about other browsers that support <LINK> - screenshots included.
• Opera 5.0 for Mac OS now also has LINK implemented.
• Mozilla (build 0.9.5) now also has LINK implemented.
• The Opera 7.0 core now has LINK support, as demonstrated by the just released Opera 7.0b1 for Windows (screenshots at Matthias Guttfeldt's pages. This means it's most likely that from here on all Opera browsers (for any platform) will have LINK support.
• There's a LINK toolbar for Firefox now.

Safari is now the only major browsers left that does not offer support for LINK. Let's hope Apple will catch up soon.