First published on October 10, 2005
Last update on November 02, 2005

User-friendlier hyperlinks

The problem

People are often confused, annoyed, etc. about the obscurity of what a hyperlink points to. In most browsers you can look at a "status bar" to review the file's name extension. But for many people that is too complicated. Even if they know where to look, many name extensions won't be recognizable to them. Besides, name extensions have no meaning on the Web anyway, so what a status bar tells you will at best be indicative, never conclusive.

Thus people find themselves accidentally (down)loading, for example, PDF files when they'd expected to load another Web page.

A possible solution

How about using CSS to help the user know in advance what sort of resource a link points to? For instance, have CSS append "[PDF]" to the end of a link that points to a PDF file. Some Web sites (Google for instance) do something similar already by using images to indicate a PDF. The downside of that approach though, is that

  1. this wil look different on every Web site and thus still confuse people - consistency is the end user's best friend.
  2. this adds content, whereas really all we want to do is present meta information.

So CSS seems like an appropriate tool here. CSS is all about presentation, and when it's part of a browser's built-in Style Sheet it can offer consistency.

Two possible approaches

  1. Target the end of the HREF attribute (CSS3-dependant)

    With this rule

    a[href$=".pdf"]:after { content: " [PDF]"; font-size: 80%; vertical-align: super }

    a browser would show a link to a file whose name extension is ".pdf" something like this. Or a link to a Word document. Etc.

  2. Target the TYPE attribute

    With this rule

    a[type="application/pdf"]:after { content: " [PDF]"; font-size: 80%; vertical-align: super }

    a browser would show a link to a file whose MIME type is known (through the link's TYPE attribute) to be "application/pdf" something like this. Or a link to a Word document. Etc.

Obviously the second approach would be preferable, given that MIME types actually have meaning on the Web. But the downside is that currently most Web publishers don't include MIME types with hyperlinks. We could settle for the first method, as "good enough" (ignoring the fact that it will probably be a while until CSS 3 reaches Recommendation status...), or we could be a little more ambitious and try to encourage Web publishers to start including MIME types with links. If browser developers would make these CSS rules part of their built-in Style Sheet that might encourage Web publishers to bother including proper TYPE attributes, because it would get them 'instant result'.

This is also an opportunity for CMS developers. Now that so many sites are CMS-driven, all it would really take to upgrade those sites is for the CMS to automatically add a TYPE attribute with correct MIME type info to every hyperlink.

Note

This applies to most, if not all file types (not to text/html of course). PDF is just used as an example. Links to ".doc" files, MP3s, AVIs, etc. would all benefit.

The above constructions are currrently (2005-10-04) supported by iCab, Mozilla and Safari - not by the dead-and-buried Internet Explorer for Mac, nor by Opera, nor by, surprise, Internet Explorer for Windows.

Original (CSS3-based) idea by Arne Johannessen