Reinventing Hypertext Links

Posted on April 24, 2003

in Code

by Chris Hester (Xanadu)

Rated 2.68 (Ratings: 22) (Add your rating)

Want more?

More articles in Code
More articles by Xanadu

Chris Hester

Member info | Full bio

User since: January 09, 2002

Last login: February 12, 2007

Articles written: 1

Consider the following example of a paragraph containing standard hypertext links:

My friend Michael came round today. He brought a new book about the singer Tom Jones called The Story Of My Life. He said he'd bought it from Stonewaters the bookstore in town. The cover depicted a silhouette of the Welsh singer's face lit from the side. Inside there was a photo of him with a beard performing live at The Brits 2003 on UK TV.

The links are all underlined - there's no easy way to tell at a glance what the links represent. Do they lead to a separate website? Or a page on the same site? Or an image or file? Although we can look at the bottom status bar of a typical browser and see the full address of the link displayed when hovering over it, you would have to hover over each link to find out where they all went. Plus an image might be displayed using HTML code as a standalone page. That would mean the address wouldn't reveal what was on the page.

It's time to clarify the situation.

Now consider the following paragraph, sharing exactly the same text, but with the links styled:

My friend Michael came round today. He brought a new book about the singer Tom Jones called The Story Of My Life. He said he'd bought it from Stonewaters the bookstore in town. The cover depicted a silhouette of the Welsh singer's face lit from the side. Inside there was a photo of him with a beard performing live at The Brits 2003 on UK TV.

To illustrate the differences I've devised a simple visual key that can be applied to all hypertext links where possible:

Normal links (underlined) = A link to a page on the same site or an email address
Italic links = A link to an image or file only
Bold links = A link to a separate website

The beauty is that the links now offer a visual clue to their destination. A user can scan a document quickly and see where the external website links are. They might choose to ignore the images (or files) linked to. They will also know that the other links will therefore take them to another page on the same site.

How To Do It

All that's needed to add 'link-aware' functionality as described above is just two extra classes in your stylesheet. Start by ensuring all links are underlined, then define a class for italic and for bold:

a {text-decoration:underline;}

.b {font-weight:bold;}

.i {font-style:italic;}

Then use these in your hypertext links to style them as required. Example: <a href="groovy.gif" class="i">Wow!</a>

Using b and i also helps you to remember what each style is for. Use b for a link to a website, or i for a link to a file or image.

The only other requirement is to tell your readers what the styled links mean. This can be done by defining them briefly, perhaps in a row at the top of the screen, or in a box at the side.

Drawbacks

Obviously there are potential problems to consider by styling links. What if the browser cannot use bold or italic? What if the font used is not markably different between bold and normal style? What if the page requires all text to be in bold or italic, or all links to be free from underlining? One solution might be to use colour instead, and display a simple key to guide the user. I consider using colour a bad idea though, because it could cause problems with monochrome devices, blind or colour-blind users. Instead you could try different fonts or even font sizes. Or unique types of underlining such as dotted lines.

Conclusion

Styled links offer a new way to make web pages more user-friendly, more accessible and more content-rich by describing the destination of the link with a visual clue. Using my technique a user can view a whole screen of links at once and choose instantly whether to follow them or not. Otherwise, text doesn't have the power to tell us where a link leads to. "Click here!" could be a link to anything. But if you style it using my guide above, you would always know what type of link it was.

The author writes articles and posts about website coding from Yorkshire in the UK, all of which can be seen on his website Design Detector.

35 comments on this article. Log in to add your comment | Rate this article:

Class names

Submitted by luminosity on April 24, 2003 - 19:39.

While I agree that it could be useful for people to be able to distinguish between the different links, I feel that your class names could have been chosen a lot better than they were. i and b don't mean anything. Classes are used to subclass the elements they're applied to. A subclass of a link that is an external link would be much better off with a classname such as external, similarly a file would be much better classed with the value file.

One other thing, too — I think that there are better ways to indicate that the links go to other places than making them bold or italic. A much more recognisable and intuitive way would probably be to use background images in a space either directly before or directly after the links. If not all browsers you needed to support this could support it properly, you could then fall-back on italic and bold for those browsers.

I agree

Submitted by marktranchant on April 25, 2003 - 00:51.

I agree with luminosity, the class names should reflect function rather than appearance.

My church web site uses a similar technique, with a class called ext to represent external links. At the moment, the only style difference is a different highlight colour on hover, but I could easily extend this if I wanted to.

The most valuable method for graphical browsers is via the title attribute, as you have also used in your examples.

Great idea

Submitted by paulnattress on April 25, 2003 - 02:12.

I like this idea very much. I agree with Mark - the title tag (as used in this article) should state what type of link it is. However, I like the idea of being able to scan a page and pick out the links to other websites. This can be useful if you are looking for a site that you know was mentioned on the site you're on. You can skip over all the internal links and check all of the external ones.

One disadvantage of making external links bold is that you're adding emphasis to external links. Is this what we want? Or should we be using another visual clue such as the background image as suggested by luminosity? I think Microsoft or IBM or some other huge company tried this on their site and it didn't work - perhaps because they used several different icons for different link types. Using one just for external links would be less complicated.

Try attribute selectors instead?

Submitted by aardvark on April 25, 2003 - 05:13.

I actually find the idea of embedding classes to be somewhat distasteful. I try to consider users of a CMS, who have no idea how to insert classes, or perhaps someone who just doesn't get it and mixes them up. Instead, I'd like to lean on selectors to do the dirty work — in this case attribute selectors. Granted, this example only works with the target attribute, which the specs have deprecated, but since I still code client sites to HTML 4.01 Transitional, and since my clients both insist on new windows and know how to set links to open in new windows in their CMS, it's a more natural approach for me.

a[target] { color :#ff0000; } a[target]:after { content: " [Opens in '" attr(target) "'] " ; } a[target="_new"] { color: #000000; } a[target="_new"]:after { content : url(/evolt/images/rating/6alt_rating01.gif); }

Now, sure, you won't see it in IE6 on Windows, but you will see it in Netscape 7, and that's one of the biggest drawbacks of this technique.

The CSS is pretty basic for the second one. It simply sets a style if there is a target attribute. I also use the after pseudo-class to write the name of the window to which it is linking.

a[target] { color :#ff0000; }<br>

a[target]:after { content: " [Opens in '" attr(target) "'] " ; }

The CSS for the third one isn't any more complex. It checks for a specific value on the target attribute. Then I use the after pseudo-class to insert an image — like an icon indicating that the link opens in a new window (represented here by a cube from this site).

a[target="_new"] { color: #000000; }

a[target="_new"]:after { content : url(/evolt/images/rating/6alt_rating01.gif); }

Yes, there are problems with this approach, too, as I've noted, but given my desire to minimize embedding classes all over the place, it works well enough for me.

last comment

Submitted by aardvark on April 25, 2003 - 05:26.

The embedded CSS is being stripped, I'll see if I can get it back in there.

Fruitsalad

Submitted by asjo on April 25, 2003 - 06:52.

Looks like fruitsalad to me.

if you write good prose and chose words to link consistently, you won't have to use style to indicate what the links link to; it will be obvious to the user.

I.e. if the text discusses at book-cover, and the words "book-cover" are a link, I expect it to be a link to a page that displays the cover being discussed (be it an image, or an Amazon-page, or somewhere else where the cover can be seen).

What do I care if the link is external or not? This is the interweb, dammit - links are supposed to be able to take you anywhere. Users know that by now.

The whole notion of internal vs. external links is so 1990's old-hat don't-leave-my-site-I'll-earn-more-banner-pennies.

Just my two cents.

New iconography - for what purpose?

Submitted by JohnColby on April 25, 2003 - 07:38.

By introducing a whole new meaning of web-page life is it not jut adding to the confusion of a web page? Somewhere there's got to be a key to what these visual representations mean - another code to go wrong or be misunderstood, another source for complaint if something is marked up incorrectly.

From the accessibility point of view devices like speech readers will not care what the type of long is, and I agree with asjo that the prose style will guide the user to a correct understanding of the page and not by differently styling links.

No, not for me, and not something I'd consider teaching.

Irrelevant

Submitted by apathetic on April 25, 2003 - 11:23.

The distinction between external and internal links are totally irrelevant to everyone but the author of the particular page. (Unless you have taken some obscure legal advice that requires the distinction.) Also, I would suggest that the distinction between file types is usually irrelevant unless linking to a particularly large file, in which case this obviously needs a stronger indicator than italic styling.

The best indicator of the destination of a particular link is the context in which it is presented. The emphasis given to links by using bold and italic styles is far more misleading and confusing than treating them equally.

in reply to some of the above comments

Submitted by Xanadu on April 25, 2003 - 11:46.

luminosity:"While I agree that it could be useful for people to be able to distinguish between the different links, I feel that your class names could have been chosen a lot better than they were. i and b don't mean anything. Classes are used to subclass the elements they're applied to. A subclass of a link that is an external link would be much better off with a classname such as external, similarly a file would be much better classed with the value file."

Good point. I chose i and b simply because they are only one letter! So a large page full of links won't receive too much code bloat. Also if the user types in the classes manually, they won't have too much extra typing.

marktranchant:"The most valuable method for graphical browsers is via the title attribute, as you have also used in your examples."

Ah well spotted! To be truthful, I only added those to follow the Evolt guidelines for articles. Again though, use of titles is no solution, as they only show up when hovering over the links. My idea offers an 'at-a-glance' solution for web screens. (And even printed pages!)

Good concept, but unusable

Submitted by noahlazar on April 27, 2003 - 08:20.

While the concept is good, there are a few problems. First, like Chris mentioned, the styling will not work if the paragraph is already bolded or italicized. Secondly, bold and italics styles are not accessible, so non-visual users (or even non-CSS browsers) cannot take advantage of this feature. Finally, it defeats the purpose of making bold/strong and italics/emphasis text stand out as part of the paragraphs' grammar.

Also, without a key or legend, people would not know what these styles are all about, making this a usability problem. However, people have gotten used to underlines being links--and dotted underlines being acronyms are becoming mainstream--so this style could catch on given some time of real-world use.

On a similar topic, what would you do to distinguish links that refer to documents (PDF, Word, etc)? I have always been a fan of showing a document's program icon next to it so that it stands out. Most people I know don't like clicking on a link just to wait a minute for Acrobat to load on their machines. They want to be told ahead of time if the link is not going to stay within their web browser. Of course, most browsers show the URL of the link's destination in the status bar, but many novice users never look there or don't even enable a status bar.

As an example, search engines like Google have a little [pdf] mark in front of the document name. I am personally in favor of showing an icon as seen throughout this NRCS web page because it is accessible (alternate text on the icon tells users what type of document it is) and it visually stands out.

Writing quality, not workarounds

Submitted by tupholme on April 27, 2003 - 11:47.

I agree with asjo too - the prose is the thing. This should make clear the context of any links, and by hijacking bold and particularly italic you are actually devaluing their potential to enhance the meaning of the prose itself. I really don't know why people don't use longer links for extra clarity - one or two words seems to be the norm, but if you really think about it it is often appropriate to use a whole phrase.

Taking the final point as an example, 'Click here!' could indeed be a link to anything, and styling it doesn't qualify it much at all. The problem is the text! I find it an extremely useful guideline to remember that any text should make sense if the links are removed, for example if it is printed. So a lazy shortcut like 'Click here for the presentation' is out, in favour of something more passive but durable such as 'A presentation is available for download'.

This is truer to the original concepts of hypertext and much more useful for the user than the addition of a style.

Prose is good...

Submitted by paulnattress on April 28, 2003 - 00:41.

I also agree with asjo - well written web copy should describe the destination/content of a link very well.

However, I disagree with asjo (and apathetic) when they say that the distinction between internal links and external links are not relevant. I think they are very relevant.

If a user is reading an article/news story/tutorial on a website, they may have a perception that that particular website is an authoritative source of information. If the page they are on links to another, I think it's important to know whether this is an external page that may not be as authoritative (or may be more authoritative) than the page they are on. At least an external site may provide a different perspective on the subject or may be more in-depth. If the user does not want to read another's take on the subject, they can ignore it. (Good copy and the internal/external link distinction will both be useful here.)

Also, if a user is comfortable in their journey through a site and they feel safe that they know where they are in the navigation, they may have confidence that going to an internal link won't get them lost. An external link gives them a whole new navigation and architecture structure.

Already present

Submitted by luminosity on April 28, 2003 - 00:54.

True, the information is important, but it's already encoded in the link. Rather than having to class it, you can use css selectors to select any link which starts with http:// that doesn't lead to the same domain.

attribute selectors

Submitted by aardvark on April 28, 2003 - 05:37.

Actually, luminosity, my example above does a very similar thing, leaning on the presence or particular value of the target attribute in order to style the link (pity the CSS doesn't show, but you can paste it into your own page and try it).

One major caveat is that MSIE doesn't support attribute selectors.

And one problem with your suggestion is that you can't use CSS2 attribute selectors to match a part of a string like that. At least not without hyphens or spaces separating distinct values [Section 5.8 Attribute Selectors from the CSS2 spec].

CSS3, however, has provisions for string matching (too bad it's still in development). You can read up on it in Section 6.3.2 Substring matching attribute selectors, where [att*=val] would do what you suggest above.

clarification

Submitted by Xanadu on April 28, 2003 - 07:48.

The example of "Click here!" perhaps shouldn't have been used as we've already trimmed all such wordage from our site at work, in order to comply with the W3C Accessibility Guidelines. Yet it's amazing how many sites still use this for links.

The problem with just using words is - can they always describe the content sufficiently in the context of the prose? Consider the example paragraphs I used in my article. Plus I'm sure some words could be ambiguous.

I've solved the problem of PDF and Office documents as links by adding their file type to the title. So "Prices April 2003" might have "PDF" come up, or "Word", or nothing if it's just another web page. I realise this isn't suitable for all browsers, but the next step would be to use a small icon next to each link as suggested above. It all depends on the client - would icons ruin the look of the page?

"click here!" and linking to documents

Submitted by paulnattress on April 28, 2003 - 07:59.

An ex-colleague of mine did some user testing and found that a lot of users actually preferred links that said "click here" as it was plainly obvious that this was a link...

On the sites that I've worked (and work) on, we've always used a convention where we tell people what type of document we are linking to, telling them how big it is, how long it will take to download and sometimes also which software they need to view the file (Acrobat Reader for example). It can be a bit bloated but solves the problem of browsers seeming to hang when they load in a PDF file.

semantics

Submitted by bedwardj on April 28, 2003 - 09:54.

How about using <cite> or possibly <q> wrapped around hyperlinks for external links? After all the w3c spec defines <cite> as an element Contain[ing] a citation or a reference to other sources.

Then your style sheets could provide style for cite a { } and q a { }.

Another Mozilla geek way to go is to add <a title="External link to LINK definition" href="http://www.w3.org/TR/html401/struct/links.html#edef-LINK" rel="nofollow"><link></a> tags in the <head> for other language versions, other formats (.e.g. PDF), relevant external links/bookmarks, etc.

Yeah, so I do not know. Six one way half dozen the other.

CSS3 selectors

Submitted by brothercake on April 29, 2003 - 08:13.

aardvark: CSS3, however, has provisions for string matching (too bad it's still in development). You can read up on it in Section 6.3.2 Substring matching attribute selectors, where [att*=val] would do what you suggest above.

This is implemented in Mozilla (and maybe Safari by now). Here's an example which prepends "[pdf]" to the text of links that point to PDF documents:

a[href*=".pdf"]:before {
	content:"[pdf] ";
	}

You can have some great fun if you throw the :not() pseudo-class in the mix. I recently made a stylesheet where links are exploded with the URL in brackets after the link text, but there were three kinds of anchors in there - internal links like href="/something/" which needed to have the domain name prepending; external links which could be written as is; and empty anchors which should be ignored. This CSS does it:

a[href*="."]:not([href*="http://"]):after {
	content:" (http://www.domain.com" attr(href) ")";
	}
	
a[href*="http://"]:after {
	content:" (" attr(href) ")";
	}

Using imagery driven by CSS

Submitted by lloydi on April 29, 2003 - 23:52.

I personally think that having three types of links will confuse me, because almost certainly people will redefine the 'default' attributes, so on one site a link that's in italics might be redefined in CSS to display completely differently. As such you'll never learn the 'standard'. Also, what happens when you wrap a link around something that's emphasises already using <em>? Or perhaps you link to something on your own site, but the link phrase is a citation that is displayed in italics? People might assume that the link is off-site when it is not. I think what aardvark suggests is the most appropriate method (even if it is not supported by everything). I would go a step further and define a set of icons for my site that are written in using the same method.

a waste of time

Submitted by mswitzer on May 1, 2003 - 07:33.

Again though, use of titles is no solution, as they only show up when hovering over the links. My idea offers an 'at-a-glance' solution for web screens. (And even printed pages!)

Do you really scan through pages only looking for links to photos? What about to other web sites? Not only does your method lessen the aesthetics of a web page, it seems like it would hinder usability, instead of enhance it.

While your idea may be good, sort of like using the acronym tag with the title attribute, the best method is still the title attribute in your anchor, and your alternative is counterproductive IMO.

RE: prose is good

Submitted by mswitzer on May 1, 2003 - 07:38.

The easy solution, is of course, adding the URL in parentheses, following the link crediting the source, which is ethically good practice.

RE: RE: prose is good

Submitted by paulnattress on May 2, 2003 - 00:17.

Adding the url is a great idea. It helps people see the links when they're reading a printed copy of a page - increasing the usability of the printed version. But do you put a full url for internal links?

What's best: (Note: these are not meant to be clickable links.)

http://www.evolt.org/Reinventing_Hypertext_Links/

/Reinventing_Hypertext_Links/

I'd like to implement this idea on one of my sites (and will feedback the results of the change) but I'm not sure on how to handle internal linking. My initial thoughts are to only show the url on external links and to keep internal links as the usual underlined, blue text.

If you don't put the full url on the page, it would at least be a good idea to use CSS to display it on the printed version. If you only know basic CSS then simply create it as a hidden class in your normal style sheet and show it in your printed style sheet. I'm sure someone who's much better at CSS than I will show us a good example of how to do this.

Print only CSS

Submitted by brothercake on May 2, 2003 - 01:47.

Well very simply:

Can be controlled by this in the screen stylesheet:

.printOnly { display:none; }

And this is the print stylesheet:

.printOnly { display:inline; }

But I prefer the CSS3 solution I posted earlier ;)

Re:Print only CSS

Submitted by mswitzer on May 2, 2003 - 04:48.

Took the type right off my keyboard - and I would only put URLs for external links as well...

printing URLs from hyperlinks

Submitted by aardvark on May 2, 2003 - 06:16.

While IE6- doesn't support this, CSS2 has provisions for doing this without using embedded <span>s. Just insert this in your print.css file (this example styles all links, you might want to be more selective by choosing links that are children of certain elements or ids on the page):

a:after { content : " [" attr(href) "] " ; }

That inserts the value of the href attribute after the link within square brackets, so a link might look like this when printed from a compliant browser:

evolt.org [http://evolt.org]

CSS2

Submitted by mswitzer on May 2, 2003 - 06:20.

Adrian,

What browsers DO fully support CSS2?

Almost all your posts start with While IE6- doesn't support this...

CSS2 support

Submitted by aardvark on May 2, 2003 - 07:32.

Not nearly enough. Seriously, CSS2 support isn't an all-or-nothing thing, and I don't know any that fully support it. The code samples above work in Opera 6, Netscape 7 (I don't have N6 on this machine to check), and a few others. As always, it's best to just check it out on whatever you can.

Also, IE6 doesn't support this post.

pure craziness

Submitted by agraetz on May 2, 2003 - 08:07.

I don't at all like this. Let a link be a link be a link. How is this really any different than giving links different colors? Most users won't know what a bold link means versus an italicized link versus a plain link. And even if they do pick up on these subtle differences, how often will they pay attention before they link? What matters is that the user knows it's hyperlink. If I'm at a site and it's going to open an link, I don't care if it's not within the site I'm in already. Seems to me that distinction would matter more to the people maintaining their own site.

Interesting Idea

Submitted by Skitso on May 15, 2003 - 15:46.

This is a valid topic, especially handy if you can get it to function to where the "ignorant" regular everyday joe can understand that these looking links take you to this type of file. It may be a hassle, but I'm definitely interested in integration some sort of link clarification into an online bookstore I'm building for a client. The tit;e attribute seems to be a great way of describing the destination, but it takes too long on hover to be effective. There must be a javascript of somethiing from dynamicdrive.com which could preform a similar function to title if only quicker. I appreciate the idea, I normally wouldn't have thought of that as I'm a "right click - new window" kind of guy who surfs with 20+ windows open.

Another take...

Submitted by Strider72 on May 16, 2003 - 14:07.

I'm a firm believer in the "Keep it simple" rule, and for the most part, I try to make a link's destination self-evident in the text of the page. When that's not easily done, I use the title attribute.

It's easy to lose perspective when hanging out with other coders, but formatting three different kinds of links seems way too complicated for the average Joe user (a.k.a. my dad), and unnecessarily so to boot. Unless you have some very specific reason why readers must know which links are local or not, I would say skip it. If I really had to do this, I would probably hard code in a little icon next to the link, with the requisite key explaining to the user what the icon means. (Though I prefer in theory to use CSS, hard-coding the icons would be necessary because of the failings of the Most Common Browser -- again we're aiming at Joe user here.)

Counter to the "Average Joe" argument of course is an exception for techie-oriented sites where you can expect your average reader to quickly grasp, and appreciate, the distinction you're making. However, bold and italic still seem to detract from the intent. Maybe border variations?

OTOH, I really love the idea of displaying the URL when printing, but is there a way to still hide the full URL from the body of the message for text-only browsers and such? It seems this would be a cumbersome break in the flow of the text for blind people using readers, for example.

showing URL in print documents...

Submitted by aardvark on May 17, 2003 - 06:37.

Strider72, to answer your last question, the URL isn't actually in the HTML after the hyperlink. The CSS I showed above is a method to have the browser insert the URL to the page content, without you needing to actually put it in the code. This means text browsers won't see it, and the only browsers that show it on the page would be following CSS incorrectly since the style should only be called when the browser is printing.

just a comment on the article

Submitted by Gargamel on August 15, 2003 - 07:20.

I think it is a good idea to categorise links in this way - but how will an uninitiated user know? To them it might look sloppy - like you've accidentaly done some links one way and some links another way. Just a minor quibble - but users won't take it for granted unless they are familiar with your site.

To Gargamel

Submitted by Xanadu on August 16, 2003 - 10:38.

As stated before, you can put a guide to the links on the site, perhaps in a small box at the top. However, I've now come to the conclusion that icons are the best way as far as types of files are concerned. So at work I've put in icons for links to Word, Excel and PDF files. Now you can tell at a glance which are which! Especially relevant following Jakob Nielsen's anti-PDF comments recently. This doesn't solve the problem of local or external links though. I've seen a couple of weblogs which use a box and an arrow symbol for external links, but to me it looks most odd.

attribute selectors for MSIE

Submitted by tarquinwj on November 19, 2003 - 05:02.

Firstly, don't any of you shout at me. I am not voicing an opinion, just demonstrating a way of doing attribute selectors in IE.

Many of you suggested using them, but your ideas fail because the WorldsMostPopularBrowser ( TM ;) doesn't support them. But it does support proprietary expressions:

a { color: expression( this.href.match(/\.pdf/) ? 'blue' : 'red' ); }

and if you want it to validate, wrap it in conditional comments.

I'm probably not going to read any of your responses, so don't bother telling me off for using non standard stuff :-)

IE Only

Submitted by mswitzer on November 19, 2003 - 05:13.

tarquinwj

»I'm probably not going to read any of your responses, so don't bother telling me off for using non standard stuff

Well then I guess I won't reply...

No, seriously, I love the fact IE supports expresions, and wish it was part of the W3C's recommendation. Yet, I don't use them simply because, even though they are useful, if I do use them, I just promote destandardization. And one day I'd really like one set of code to work across all platforms, so why support code that obviously will not.

No yelling ;) just my reasons for not using a very good technology (you can include IE filters here too)

Start of page header

Submit

Article Categories

Highest rated articles