Links Want To Be Links

This document explains why you, as a Web page author, should not try to prevent Web browsers from displaying textual links underlined and image links with borders around them. It also discusses common mistakes in setting (suggesting) colors for textual links. In special cases, it might actually help users if you "tailor" link presentation; there are both HTML and CSS methods for that. The beauty of textual links is explained and compared with the drawbacks of non-textual links and pseudo-links like buttons. Finally we present various ways of "animating" or otherwise enhancing links without destroying their natural beauty.

An older version of this document has also been published as an article with more stylish appearance at


Links are our friends
but what are they, really?

Linking turns texts to hypertext, and hypertextuality is among the key factors that make the World-Wide Web a web of interconnected things. Using links on your Web pages, you can conveniently let your readers find background information, technical details, definitions of terms, alternative presentations, etc., on your pages or somewhere else. You can also set up "hypertextual tables of content", and you can chain pages together using links to "previous" and "next" pages. That way you can keep the size of individual pages reasonable, which is essential for fast accessibility.

By itself, a link is a relation between things which can be documents or parts of documents or locations in documents. In other words, a link is a pointer or reference. A link does not "do" anything, just as text like "see p. 42" in a book does not do anything. It is something that can be followed, by a browser on user command, or by an indexing robot, or by some other software.

Indexing robots (aka "spiders" or "crawlers") are essential for search engines, which in turn are crucial for users' ability to find Web pages. There's a lot of talk about being "search engine friendly", and there are widespread myths about the importance of meta tags and submitting your pages to search engines. But how do indexing robots find pages? Mainly by following links. So in order to let them find your subpages now and in the future in a natural way, use normal links to them. Yet, many authors prefer using fancy imitations of links ->.

The icon at the end of the preceding paragraph exemplifies a method of attaching "flags" to links ->. in order to indicate the type of a link. Here it indicates that the link preceding it is a forward reference, pointing to a location later in the same document. Thus, it hopefully helps the reader in deciding whether to follow the link or not.

Example: On IE 4, right click gives the following menu:
Open in New Window
Save Target As...
Print Target
Copu Shortcut
Add to Favorites

Even if we don't count indexing robots, which follow links their own ways, following a link doesn't mean just clicking on a link and getting the linked page onto screen. Authors often ask how to open a link in a new window or how to "download" a file without "opening it on a browser". These questions reflect ignorance of what links are and how the Web works with different media types. But the situation also illustrates how misleading it is to identify a link with one common way of using links. In particular, on popular browsers, the user can use the right button of the mouse to get a menu of alternatives like "open in current window", "open in new window", and "save onto local disk". Usually authors' attempts to dictate the ways in which links can be followed will just make things more difficult.

Links want to get noticed

It belongs to the very basic functionality of a Web browser to indicate links as links. How they do that may vary greatly, depending on the browser and its settings. And it belongs to the very basic skills needed in Web browsing to be able to recognize a link as displayed on one's browser and to follow a link. There is very little you can do as an ordinary Web author to improve the browsers or educate the users. What you can do is that you don't prevent browsers from doing their job or users from making use of that.

Recognizability isn't enough. In visual browsing, links should be recognizable on quick scanning. Web users' typical reading habits involve scanning for interesting headings, emphasized texts, images, and other visually distinctive material. Sometimes they (we) read texts in detail; it is even more rare to move the cursor over a particular piece of text or other material; and this answers the suggestion that users can recognize links as links from "tooltips" or from text color (and other properties) changing on "mouseover". The preceding sentence contains one word which is a link, just for illustration; it actually leads to a somewhat one-sided definition. You should have no difficulty in noticing which word is a link, just because I did nothing to suggest any particular presentation of links.

Links want to look normal

This document mainly discusses the appearance of links on visual browsers, such as Internet Explorer, Firefox, Chrome, and Opera. They have different ways of displaying links by default, and there are several ways to change the defaults. However there are many similarities, and some browser features in this area can be regarded as so common that a Web author should usually avoid trying anything that might cause confusion in a typical browsing environment. Whether you like the colors commonly used as link indication by browser defaults is up to you - if you don't, you can change things in your browsing environment. But it is important to realize that if you use such blue colors for some texts which are not links, a very large percentage of your readers will assume that they are links and get frustrated and confused. Similarly, if you manage to prevent browsers from using their normal presentation of links, it's usually a Pyrrhic victory.

How underlining may help

In printed matter, underlining usually indicates emphasis. (Sometimes it could make some other distinction, e.g. in linguistics one might underline expressions in the object language.) For good or bad, Web browsers generally don't use such a convention; rather, many of them by default use underlining for links. Someone might say that this is one form of emphasis. But indicating something as more important than normal text is logically different from setting up a link. Some text could be emphasized, using e.g. the em element, quite independently of its being or not being a link. And quite often links are included for the same purpose as footnotes are given in printed publications: to provide information which is, to the average reader at least, less important than normal text!

To many people, underlining means a link. Simplistic as such thinking can be, it's a reality. As a consequence, you should not try to use underlining for anything but links. In particular, you should not use the u element, which is text-level markup for underlining. Rare exceptions to this consist of specialities like referring, typically in a computer program manual, to some text which is underlined on paper or on screen, e.g. "the first item in the menu is File".

A more common problem than attempts to underline non-link texts is that authors often want to prevent browsers from underlining links. Suppressing link underlines seems to be one of the most frequently asked trivial questions on Web authoring, and it seems to be one of the most popular uses of stylesheets. It's mentioned as number 1 in the (assumably somewhat sarcastic) document 5 cheap CSS tricks at the Website Abstraction site.

Many people would agree that underlining is per se the wrong way to indicate texts as links. But it's one thing to have an opinion about browser behavior and another thing to try to force other people's browsers to behave in a certain way.

If you have a strong opinion about it, think what I would feel, as your potential reader, if I have an equally strong but opposite opinion and you manage to force me to view your page your way? (Right, I'd most probably leave your page at once.)

But there is also a very objective reason not to fight: underlining can be the only way in which a browser indicates a link as a link. Authors often think that colors do the job, but that's not something you can really count on. It is a basic accessibility requirement that one should avoid relying on colors as the only method of conveying some information. See Web Content Accessibility Guidelines, principle 2: Don't rely on color alone. The following simple examples illustrate this:

It is fairly popular among Web authors to try to suppress underlining of links and try to re-establish it on "mouseover->. Well, it quite often happens that the former attempt is successful but the latter is not. More importantly, underlining is most essential when the link is not focused on, because it helps the user seeing it there is something that can be meaningfully focused on!

It has been argued that users can set their browsers to override authors' presentational "commands" if they really need to, e.g. force the browser use underlining of links if links would otherwise be indistinguishable from normal text. That's true in a sense, in most cases, but users need to know that and take the extra trouble. But generally, robust Web authoring should be prepared to having stylistic suggestions overridden by user settings, not rely on that taking place!

Naturally, you should not try to force other people's browsers to underline links on your pages either. There can be very good reasons why people have configured their browsers not to use underlines.

What about "the ugly borders"?

[Information about dog breeds] If an image is used as a link, then typical visual browsers by default indicate it as a link by drawing borders around it. Typically the borders are of the same color as the browser uses for textual links. This means that visited and unvisited links are displayed in different colors.

One of the most common questions on HTML authoring is how to get rid of the "ugly border", and the answer -> is technically simple: add the attribute border="0" into the img tag. This cannot force anything; browsers may still override it. For example. a user can write a user's style sheet which suggests borders around image links and declare the suggestions as !important, to override author's stylesheets.

* But the border="0" attribute mostly works; and that exactly is the problem. If there are no borders around an image, the user does not see what images are links. Browsing becomes guesswork, trial and error.

Removing the borders is even more harmful than removing link underlines <-. since with textual links, there's a considerable chance that they will be seen in a color which tells the user they're links (or perhaps with a frame around them, or something). For image links, it seems that the border is the only way for browsers to indicate them as links, so does it make sense to try to prevent that?

It has been said that users can move the cursor around to see which images are links, but that's really not a very brilliant idea. It turns immediate visual perception (via just taking a glance over the page) to a game which is not fun at all. Generally the desire to remove borders relies on the assumption that users behave or should behave in the "click on everything, it might be a link" fashion, or at least in the "don't stop waving your mouse hand, you just might see a kewl tooltip or a status line message which tells you something" fashion.

A border around an image can surely spoil the esthetic appearance of an image to some extent. Sometimes the effect is really bad indeed. However, removing a vital usability feature is not a solution except in special cases ->. And it's difficult to make any constructive suggestion on how browsers should indicate images as links in some other way, especially if they should make the distinction between unvisited, visited, hovered, and active links. The solution is very simple: Don't use images as links. We'll find some exceptions to this rule, but for the vast majority of images used as links nowadays, the best advice is: use textual links instead, and if the image itself is somehow useful or entertaining, let images be images, and let links be links. You could simply write an image and a textual link, and if they relate to each other, group them together using suitable markup.

The "dotted line" around an image

One more presentational feature needs to be mentioned here: the "selection rectangle", or more generally a selection outline, which is a border-like phenomenon. On some browsers, when an image which is a link (or an area in a client-side image map) is clicked on, a thin dotted line appears that outlines the image or area. This may happen for textual links too. The line mostly vanishes soon as the linked resource is displayed. It can however be a nice usability feature if there is some delay, since the user knows that the browser is reacting to the click. Moreover, if the line remains there, as happens when frames are used, the line is a useful visual indication of which link was last clicked on. If the user proceeds from one link to another using "tabbing", then the "selection rectangle" also appears, indicating where the focus is, which is rather essential to know in such usage (though the browser may additionally indicate the focus with a color change). Strangely, authors often want to remove this nice feature!

The selection rectangle feature has generally been removed from browsers, perhaps partly due to complaints from authors. You can suggest such a behavior (or suggest its absence, for browsers that have it by default) using the outline property as defined in CSS2. You would use it in conjunction with the :focus or :active pseudo-class. Their interpretation varies by browser.

Due to the changes in browsers, the following notes are mostly historical.

* The hack of using the event attribute onfocus="this.blur()" in the a tag has been suggested, and it seems to "work" on IE 4. However, such an attribute logically says that the element should lose focus whenever it receives focus, and the natural interpretation (which might well be applied by future browsers) would be that the link can never be selected! In fact, such browser behavior for the same attribute has been observed in another context, namely for text input fields in forms, and presented as a trick for making the field read-only through being unselectable! Moreover, for a link the attribute has the defined effect in the sense that the user cannot select the link by tabbing. And this seems to imply, on IE, that the onfocus="this.blur()" hack breaks the tabbing sequence: one cannot proceed to links after it by tabbing. Note that tabbing is an important accessibility issue. In some cases, you can make the problems smaller if you replace this.blur() by code that focuses on the next field instead. Problems can also be alleviated by adding conditionality into the JavaScript code (if(navigator.appName == 'Microsoft Internet Explorer')) so that it does not affect browsers other than IE.

There's also a modification of the method described above: it uses onclick instead of onfocus. This avoids some of the problems, since the element can be reached by tabbing (and the dotted line then appears, to disappear later when the element is clicked on). The following fundamental problem still remains: after following a link and returning to the page, the user cannot conveniently proceed by tabbing. Since the focus was deliberately lost, he has to start over, from the beginning, not where he was. The point is that blur() doesn't just remove the dotted line; it removes the focus itself, not just its visual indication.

It has been reported that onfocus="this.hideFocus=true" could be used to prevent the selection rectangle on IE 5.5, without causing problems on other browsers. According to Microsoft's documentation of hideFocus, it could also be used as an HTML attribute. On the other hand, Jim Ley has mentioned: "onclick="this.hideFocus=true" onblur="this.hideFocus=false" is better as this lets the user see the focus indicator before they activate the link, only hiding it when it's clicked, and then reseting so it will appear visible next time you tab to it".

How recognized link colors help

Jakob Nielsen, the usability expert, wrote the alertbox Top Ten Mistakes of Web Design in 1996, making a very important point on link colors:

8. Non-Standard Link Colors

Links to pages that have not been seen by the user are blue; links to previously seen pages are purple or red. Don't mess with these colors since the ability to understand what links have been followed is one of the few navigational aides that is standard in most web browsers. Consistency is key to teaching users what the link colors mean.

In fact, red color is more typically used for active links, and due to its usual connotations it wouldn't be particularly suitable for visited links. Thus, one can say even stronger than Nielsen did: some flavor of purple is the de facto standard for visited links. This serves the additional purpose of making them less prominent than unvisited links, yet different from normal text.

In a review of the mistakes in 1999, Nielsen classifies this error as "severe" and explains it more:

Continues to be a problem since users rely on the link colors to understand what parts of the site they have visited. I often see users bounce repeatedly among a small set of pages, not knowing that they are going back to the same page again and again.

Playing with link colors just because of the author's own esthetic preferences, or ideas of what's "cool", is undoubtedly one of most obvious and most harmful symptoms of bad page design. It is often based on a misguided attempt to design a page or site which "stands on its own". But as Keith Instone has put it in his Usability Heuristics for the Web:

- - your site is not an island. Users will be jumping onto (and off of) your site from others, so you need to fit in with the rest of the Web to some degree. Custom link colors is just one example where it may work well for your site but since it could conflict with the rest of the Web, it may make your site hard to use.

There are two distinct points actually:

  1. visited and unvisited links should look different from each other (and from normal text)
  2. the colors or other means of making them look different should be familiar to the user.

The best an author can do about this is to do nothing with link colors. If however an author suggests link colors, the suggestions should correspond to typical browser defaults: blue (#00f in one CSS color notation) for unvisited links, purple (roughly #909) for visited links, or something reasonably close to them. This is not as good as leaving the colors alone, but it will be OK to people who use typical browsers with default settings, and we can hope that people who have changed the settings know how to override authors' presentational suggestions if needed. The use of such colors for links has implications on the overall color design of a page, to be discussed later in the "how to" section.

Reversely, if you have decided to suggest any colors or backgrounds on your page, you should normally suggest all the link colors too. (However, a suggestion like a colored border around an element could be made as a "standalone" suggestion.) The discussion above suggests that you shouldn't deviate too much from "normal", which means rather light background and dark text. For example, suggesting black or dark blue background would imply that you can't use normal link colors. See also Colors in Dan's Web Tips. But if you decide to use dark background, make sure the text and link colors are distinguishable against it, and consider suggesting an increased font size and a sans-serif font. The reason is that text which is legible when black on white tends to become rather hard to read when white on black unless you try to help by making it sans-serif and larger than normal.

The impact of browsers' ideas of "visited"

The preceding discussion may have given a bit overoptimistic idea of browsers displaying visited and unvisited links differently. The problem is that browsers have different ideas of what it means to be visited. (They have different and usually user-configurable rules for reverting a visited page to unvisited state after some period of time, but here we discuss a different issue.)

Consider a page containing links to two locations on another page, e.g. to the definition of "glyph" and description of Unicode" in my tutorial on character code issues. If you follow the first link and return, then Netscape shows the other link as unvisited but IE turns it too to visited. Which is better? Hard to tell. But it's surely sometimes inconvenient that you cannot see which locations of a page you have checked by following direct links to them.

There's nothing you can do about it in any direct way. But in site design, this is an issue to be remembered when considering whether to write one long page or a set of interlinked pages and which format is the one presented as primary to users if you have both formats. If you have relatively small interlinked pages, then the odds are that even IE's concept of "visited" corresponds to what the user has actually looked at.

Could "tailored" link presentation ever help the user?

Let us begin with a simple case where it might make sense to modify link presentation, not so much for usefulness but for esthetic reasons on which most people could agree. Assume that our page is a thumbnail gallery, i.e. a collection of reduced-size images which are links to full-size versions. Colored borders might slightly distract the user's attention from the visual content itself. And since the distinction between visited and unvisited links isn't usually essential in such cases, we might explicitly tell the user that all pictures are links to full-size images and suggest border removal. This could be done either using the border="0" attribute <- in each img element or, in a simpler way which doesn't yet work quite that often, using just the stylesheet -> rule img {border:0;}. On the other hand, an image gallery can be just fine even if the images have borders around them.

As regards to removing underlines, consider the rather special case of my page containing a table of characters so that each character is a link, referring to a description of that character. It is clearly better if the characters are not underlined - especially since the table contains the low line (underline) character and some other characters for which underlining would be confusing. Naturally there is an explicit statement about the characters being links.

A different special case, somewhat analogous to a thumbnail page (where all images are links) would be a page where all words (except perhaps some headings) are links. It might be better to explain this and try to suppress the underlining, since it is inconvenient to read text where all words are underlined or otherwise different from normal text. This could be useful for language teaching and study material where every word is e.g. a link to a glossary entry. But note that e.g. the texts of the Perseus project do not apply such techniques, although most words in the texts are links. (You can read, say, Caesar's Gallic War in Latin so that almost every word is a link to information about the meaning and grammatical form of the word. Very nice if you know some Latin and wish to learn more.) In fact, the word "most" gives a hint why the technique wouldn't necessary be such a great idea. What would you do if you need to introduce words which are not links, for some reason? Moreover, if the underlining seriously bothers the user, he can probably turn it off in his browser's setting. But this example illustrates what kinds of possible reasons related to the content and structure of the page there might be to affect link presentation.

  • unvisited "official" link
  • visited "official" link
  • unvisited "unofficial" link
  • visited "unofficial" link
  • any activated link.

Finally, probably the most common reason for affecting link presentation is to make different links look different. As an example, consider my attempt to create a hypertext version of an RFC. It contains both "official" links, corresponding to references in the RFC itself, and "unofficial" links, which I wrote to refer to information which might be useful to readers. I'm not that happy with the results. Basically, I need six different colors (or actually more - we should consider "hover" colors too): two sets of unvisited, visited, and active links. It would clearly be harmful to remove one essential distinction when introducing another one. It seems acceptable to use the same "active" color for both links, but this still means five colors which must be clearly distinguishable from each other and from other colors used on the page. And the color scheme then becomes rather unintuitive and difficult to remember. (An author might consider using frames to make a legend visible permanently, but this would suffer from the usual drawbacks of frames.)

Especially if you have created a downloadable set of pages so that people can study them offline, too, it would be very useful to distinguish between "internal" and "external" links. Internal would mean a link which refers to something within the downloadable set, and external would thus in practice mean a link which works in online use only.

Yet another distinction one might wish to make is based on the language of the referred document. For example, a document in Spanish and mainly intended for Spanish audience might present links to documents in English (or generally languages other than Spanish) differently from links to Spanish documents. This would save those users' time who can't read English. In principle, one could use the hreflang attribute and let browsers take care of the rest; but unfortunately browsers don't even try to support that attribute. But such distinctions can be done in a natural way by making the link text appear in the language of the referred document. A link like El ingenioso hidalgo don Quijote de la Mancha suggests in a natural way that it's useful only if you know some Spanish. In special cases, when the language is not obvious from the link text or context, you might add a "flag" -> like [es] (or [in Spanish]) to the link. Just remember not to use country flags!

So how could it be done?

Most methods of affecting link presentation are based on stylesheets, or CSS. To learn to use stylesheets, you need to study a good tutorial, and using them you need to consult CSS specifications and documents describing actual browser behavior. For some essential links, see my document How to use stylesheets?. Stylesheets are, by design and as actually implemented, suggestions only, and they can be ignored by browsers for various reasons, some of which have been explained in this document. The same applies to presentational HTML markup, too.

Text emphasis

First let's mention some simple but useful HTML methods. You can put text-level markup around a href elements. To emphasize a link, you can use the strong element which is typically displayed in bold face. To indicate a link as less important, you can, in the absence of more logical alternatives, use the small element.

No underline

You can suggest suppression of underlining by specifying text-decoration : none in a stylesheet ->. For example, the character table page mentioned above uses the following technique: The table tag has the attribute class="codetable" and the associated stylesheet contains the rule
.codetable tr td a {text-decoration:none; font-size:large}
which can be read as follows: if there is an element belonging to class codetable and containing a table row containing a cell containing an A element, please do not use any text decoration (like underlining) and use a large font. This could in principle be written in a simpler way, but the rule above takes some browser bugs into account. (The increased font size is unrelated to underlining of course, but useful in this context.)

No border, or a modified border

Suppression of borders can be suggested in a stylesheet -> by assigning a zero value to the border property. To do that for all images on a page (be careful!), such as for a thumbnail page, you would just write
img { border : 0; }
into a stylesheet. Normal CSS techniques (selectors) can be used to limit the suppression of borders to some img elements only. You might, alternatively or additionally, put the attribute border="0" into img elements.

You might also wish to modify the border. For example, instead of regarding the border as a nuisance, you might regard it as so useful that you wish to make it wider. This might help users in distinguishing between different colors and thereby between visited and unvisited links. If you use the border attribute in HTML, its value must be a plain number, interpreted as pixels. In a stylesheet, a plain number (other than 0) must not be used; instead, you need to include a unit, such as px or em. If you use both the attribute and the stylesheet property, the latter "wins", when stylesheet support is enabled. Example (with a rather wide border, for illustration):

<a href=""
><img alt="" src="ball.gif" align="right" border="6"
with the following rule in a style sheet:
img.special-border { border: solid 0.4em; }

Link colors

Suggesting link colors looks deceptively easy, if you are familiar with the basics of RGB colors. If you use "browser-safe" colors only, you can use simple color notation in CSS: #rgb where each of r, g, b is one of 0, 3, 6, 9, c, f (corresponding to 00, 33, 66, 99, cc, ff in 6-digit color notation), specifying the intensity of red, green, and blue light, respectively. You can write e.g.

a:link { color : #33f; }

into a stylesheet -> to suggest that unvisited links appear in color #33f which is a blue color slightly lighter than "pure blue" (#00f).

However, suggesting link colors the right way takes more. It's a matter of knowing the correct approach and applying it consistently. The motivation for the rules can be found in material on CSS; here we just list the rules:

  1. Always suggest text color, background color, and background image together.
  2. When suggesting link colors, suggest them for unvisited, visited, hovered, and active links, in this order.
  3. In your HTML markup, do not nest other markup inside a href markup.

As regards to rules 1 and 2, compare them with the reasons for the good old recommendations to set all body attributes in HTML markup if you set one of them. The basic idea is the same: provide a consistent set of settings which is not disturbed by unknown browser defaults or user settings. The colors must "play together" to work well, so you just can't afford a combination of your colors and some unknown colors. Other presentational properties, like font faces and sizes, may well come from user settings, of course, and you should not try to affect them unless you have good reasons to that.


a:link    { color : #009; background : #fff; }
a:visited { color : #609; background : #fff; }
:link:hover, :visited:hover 
          { color : #f66; background : #fff; }
:link:active, :visited:active
          { color : #f00; background : #fff; }

For an explanation of what such selectors mean in detail, see the CSS2 Specification, sections The link pseudo-classes: :link and :visited and The dynamic pseudo-classes: :hover, :active, and :focus.

The example above more or less corresponds to typical browser defaults. Changing the color codes you can modify the presentation, but think twice before making them very different from the defaults. Note: a:hover settings (a CSS2 feature) are not supported by all browsers yet. It is very useful to have them though, since otherwise you would remove a usability feature on those browsers which by default use a specific "hover" color. (Setting the other link colors overrides that default.)

Rule 3 means, for example, that in order to strongly emphasize a link, you put the a href markup inside the strong markup, not vice versa. You can deviate from this, but then you should write a more complicated style sheet which handles such nested markup in a manner which somehow preserves the link color differences. (For example, if a user style sheet specifies brown color for strong elements, such differences would be lost unless your author style sheet handles the problem.)

It is sometimes suggested that font color markup be used to specify font color, since it's "plain HTML" and supposed to work on older, non-stylesheet browsers too. This means markup like <a href="URL"><font color="#3333ff">link text</font></a> (nesting a and font the other way around does not have the desired effect). This "works" on most visual browsers (though the effect is overridden if there is a user style sheet which suggests link colors). The fundamental problem is that this trick destroys the crucial distinction between unvisited and visited links <-.

Mouseover effects

The technique discussed above can also be used to highlight links when they are selected by the user, i.e. to achieve "mouseover" effects more easily than using JavaScript. You simply specify suitable rules for :link:hover and :visited:hover pseudoelements, instead of or in addition to the color rules discussed above. For example, you could - as I've done for the link in this paragraph - suggest that links turn bold on mouseover (which is for most practical purposes the same as on hover):

:link:hover, :visited:hover { font-weight : bold; }

This could be used without any other stylesheet -> rules. It does not remove any normal browser behavior, just suggests an additional feature, and it works when client-side scripting is disabled, too.

Note that the CSS approach of using :hover is limited to making stylistic suggestions on presentation, such as changing font properties, adding or removing underlining, etc., although this may involve "dynamic" behavior and although there will be quite a lot of things you can do that way, as CSS and support to it evolves. Generally, if you wish to make things happen on mouseover, you need to use client-side scripting, which imples essential limitations on functionality. For example, if you wish to make a separate window pop up on mouseover, you could use a normal link together with an onmouseover event attribute. A simple example (which has been applied to the preceding link): The head part of a document might have

<script type="text/javascript"><!--
function popup() {'popup.html','','width=300,height=150,'+
and the body part might then contain
<a href=""
 title="Events and Event Handlers"
>event attribute</a>

But beware that such popup windows are generally regarded as a nuisance. At least make sure you don't leave the unexperienced user with a window he can't close or enlargen or otherwise manipulate! For technical information, see JavaScript window FAQ and WebReference's Window Spawning and Remotes. If you really have meaningful use for such techniques, consider using frames instead of popup windows. You could divide the window into a main frame and a small "footnote frame" under it, and use e.g. onmouseover to display explanatory texts about links (and other elements) in the lower frame.

Making different links look different

If you wish to suggest link colors in a manner which distinguishes between different types of links <-, use selectors in your stylesheet ->. To take a typical example, in order to distinguish between "external" and "internal" links, you would extend our basic example of suggesting link colors: write e.g. the attribute class="ext" to all a href elements which are external links, and write e.g. the stylesheet rules

a:link    { color : #009; background : #fff none; }
a:visited { color : #609; background : #fff none; }
:link:hover, :visited:hover  { color : #f66; background : #fff none; }
a:active  { color : #f00; background : #fff none; }
a.ext:link    { color : #036; background : #fff none; }
a.ext:visited { color : #336; background : #fff none; }
a.ext:link:hover, a.ext:link:visited
   { color : #f66; background : #fff none; }
a.ext:link:active, a.ext:visited:active
   { color : #f00; background : #fff none; }

Note that the active and hover colors are the same for all links here, but they need to specified explicitly for external links. This is one of the pitfalls of CSS, caused by so-called specificity rules.

Can you make multidimensional classifications of links? Say, can you use different colors for internal and external links and make a visual distinction between links to tutorials and links to technical references using some other method, say different fonts? In principle yes. But it's not easy. In particular, it is possible in HTML to specify that an element belongs to several classes, say class="external tutorial".

As an alternative approach to making distinctions between different types of links, consider the following methods which let you avoid interfering with link colors at all (i.e. you'd let colors default to what the user is accustomed to, which is almost always the optimal option):

  1. Use different font faces for different links. At the simplest, you could suggest:
      { font-family : "Times New Roman", serif; }
    a.ext:link, a.ext:visited
      { font-family : Verdana, Arial, Helvetica, sans-serif; }
  2. Use bold face for some links, e.g.
    a.ext:link, a.ext:visited
      { font-weight : bold; }

Attaching "flags" to links

The most reliable method of indicating distinctions between different types of links is to add textual explanations. They need not be long. You can use, say, the string "[X]" after each external link, and put somewhere near the beginning an explanation (legend) of the notation(s). You might provide image alternatives for them, too (using markup like <img alt="[X]" src="ext.gif">, but it's probably difficult to develop good icons for such purposes in most cases.

Since such "flags" are part of the normal textual content, they work on all visual browsers as well as on non-visual user agents. Note that although a legend is needed, just as you'd need one if you used a color scheme, the notation could be relatively intuitive and easy to remember, as opposite to color assignments which would be rather arbitrary.

Suggested type indicators for links
[?] "quick info"; the link leads to a short description (typically, a few lines of text, perhaps with an illustration) of the concept, such as a dictionary or encyclopedia entry
[D] definition; the link leads to a document providing a definition of the word or phrase appearing as the link text; note: [?] means informal overview for general audience whereas [D] might refer to a rigorous, or even formalized, definition
[R] reference; the links refers to a detailed reference document on the topic of the text of the link
[T] tutorial; the link is intended primarily for people to whom the term appearing as the link text is unknown or almost unknown
[L] link list; the link leads to a document containing several different links related to the topic area of the link text
[B] bibliographic data; the link refers to a document containing information about a book or other document which is mentioned as the link text, rather than the document itself
[->] forward reference, to a location later in the same document
[<-] backward reference, to a location preceding the current one in the same document.

In the HTML markup, it's probably best to separate such a notation from the preceding text by a no-break space, &nbsp;, instead of a normal space or line break, to avoid the possibity that a line split occurs between them. Also note that IE may split strings like [<-] or [->] unless you use nonstandard nobr markup to prevent that.

These notations would help in avoiding disappointments and waste of time. I suppose you've seen and followed links like ISO 8879 just to see that they lead basically to ordering information only, not to an online version of the document you're interested in. So [B] might help. Similarly, [<-] may help in realizing that a link leads to something you've already read. To someone who has jumped into the middle of a document, the same notation would be informative, too.

The notations [->] and [<-] don't look nice, but they are probably the best we can achieve using short sequences of ASCII characters. You might wish to consider using small images, naturally with alt="->" and alt="<-". Or, in special occasions where you need to assume the availability of a rich character repertoire anyway, you might use some Unicode characters in the Arrows block, e.g. using the numeric character references &#8594; and &#8592; (denoting rightwards arrow → and leftwards arrow ←). Obviously, these "flags" would not be needed in cases where the textual context of the link explicitly says that the link is a forward or backward reference.

Sometimes you might make such a string itself a link, especially if you don't want to cause a long text such as the name of a publication to be presented in "link style". Thus, in particular, you could use cite markup and associated stylistic suggestions and have it followed by separate notation which acts as a link. It's probably a good idea to make the link text appear in bold face then, because that way the color difference between visited and unvisited link is easier to see. Example: HTML [R], ISO 8879 [B]. This way you could also simulate a "multilink", i.e. a link which would point to different documents depending on user selection: CGI [?] [D] [L] (An obvious way to simulate a multilink is of course to write a separate document which contains the alternatives as normal links, with annotations, and use a normal link which refers to that document. That approach however involves an extra step by the user in following links.

The beauty of textual links
and the drawbacks of the surrogates

We have presented some reasons to avoid using images as links. Here we take a more positive look: it's not basically a matter of what's wrong with image links but what's so nice about text links.

How they work

Consider the process of detecting and using a normal, textual link:

  1. The link text is seen (or heard) and recognized <- as an unvisited or visited link, unless the author has taken extra measures to prevent that. Note that the link text appears (by default) in normal font face and size; thus it adapts to users' preferences in this regard.
  2. The link text and any information surrounding it can be used to explain to the user what the link leads to. Note that in link text, you can use text level markup e.g. to emphasize words.
  3. The user may then focus on the link, using the mouse, or by tabbing, or some other way (like access keys). Browsers may indicated a focused, or "hovered" link in some particular way. Some "tooltips" -> or other advisory information may pop up, too, helping the user in making an informed decision whether to follow the link or not.
  4. A link can typically be followed in several ways ->: opening it in the current window, or in a new window, or just downloading the resource onto the user's hard disk.
  5. If the user decides to follow the link and e.g. clicks on it, an indication of the request being processed may appear (such as "selection rectangle" <- appearing and/or the link color turning to one that indicates "active" link).
  6. When the linked resource appears in the browser window, its URL appears too, and the resource can be bookmarked.

We have stated the obvious, namely the typical properties of textual links, to emphasize that other types of links or their surrogates usually lack one or more of those well-known properties. Consequently, they imply deviation from the users' normal mode of surfing. They are more restrictive, too; consider, when reading about the surrogates in the sequel, for example what you would do if you wanted to open the "linked" resource in a new window.

To make the best possible use of the beauty of textual links, write descriptive but concise link texts. Obviously, texts like "Click here" don't satisfy this requirement - and they look really stupid on paper, and sound stupid when read aloud! There are also several other dangerous words which you should avoid in link texts and around them. Ideally, the link construct <a href="URL">link text</a> should be written so that the URL/link text pair makes perfect sense even in isolation. (Extracting such pairs from a document should give a nice list of resources that the document links to.) This is sometimes hard to achieve without making the text look unnatural; especially in such cases, consider adding a title attribute -> as an advisory text which provides additional information.

For further illustration, let us consider some alternatives. In all cases, we wish to link to's main page, i.e., and possibly to some major subpages there, too. (Flash technology is not discussed here; but when used for navigation, it suffers from serious usability problems; see Jakob Nielsen's article Flash: 99% Bad.)

Grouping textual links

You can organize sets of links in various ways, e.g. as lists or tables. To take a simple example, the following small table contains links to's main page and to top level subpages as a nice, compact set: Articles FAQs Games BBS Resources Software Books Downloads About Beta Find

One problem with such a table is that it may force horizontal scrolling if the browser window is narrow. So unless the set of links is rather small, a simple sequence of links might be better. You would just put the links into a paragraph and separate them with spaces or, preferably, with spaces and some separator characters like vertical line "|". Since it is preferable not to break a line before the separator, it's best to use a no-break space before it; and after the separator, you can use a space or a newline (which are equivalent). So the markup would be something like
<p><a href="URL1">text1</a>&nbsp;|
<a href="URL1">text1</a>
resulting in a presentation which automatically adapts to the window width:

Articles | FAQs | Games | BBS | Resources | Software | Books | Downloads | About | Beta | Find

For large collections of links, there are several ways of organizing them e.g. into tables. You could also use nested lists (typically, a UL element where the list items, LI elements, contain lists) especially when setting up a hierarchic table of content; see the ToC of a hypertext version of RFC 2396 for an example.

Adorned textual links

An unadorned textual link like is extremely suitable for normal use. It is particularly convenient when it is to appear in running text, since it has the same text size as normal text.

Text emphasis -> can be applied however to create an emphasized link like

One could use increased font size like or even in some cases. In running text, this is usually acceptable only if the link is probably displayed at the first line.

Using a colored presentation would be more risky, for reasons explained above, but a careful slight change in background color might be acceptable and useful. One might use a very light gray background like #f6f9f6 for the document body in general and pure white for links. This might add a feature which makes links inside running text, say, to "stand out" a bit more clearly.

Fancy colors like those used on the's main page itself might work in some cases, but only if it is evident that the texts are links and if it does not matter too much that the unvisited/visited distinction is lost. It does matter a lot e.g. on a page which contains a list of links leading to separate documents, like a FAQ index page, say JavaScript VFAQ page. How else could the user keep track of which answers he has consulted when trying to educate himself in general or to find an answer to a particular question? And even on basic navigational pages, such colors, suppressing the distinction between unvisited and visited links, might make life harder to first-time visitors. They have problems in figuring out how the classification of things really works; the link names often don't say much. Perhaps one could suggest that unvisited links be underlined and visited links be not underlined?

There are many other variations one could apply to textual links, like suggesting a particular font face or putting them into boxes, either using stylesheets -> or the relatively harmless hack of using a one-cell table.

Images as links

Let us then consider the use of an image, like the logo, as a link:

You should write no space or line break between the ">" which terminates the img tag and the </a> tag. Otherwise some browsers display an odd spot.

This works reasonably well, if it has been designed robustly in the sense of including a useful alt attribute. One might say that we use a textual link as the starting point and fallback. Instead of regarding the alt text as a surrogate for the image, we start from the simple link
<a href=""></a>
and just replace the content by the element <img alt="" src="...">, which provides an image alternative to the text. This way, and assuming you do not remove the "ugly" border, an image link might work almost as well as a textual link.

If you have a company logo on all pages, you might make it a link to the company's main page. People might guess it could be a link and get accustomed to using it; but then you would need to make sure every occurrence of that logo is a link! Moreover, don't rely on a logo as a link. Most probably you can find a natural way of including a textual link too, e.g. by making the first occurrence of the company's name a link.

Image maps

Image maps are surprisingly often used for "navigational" links, despite serious accessibility problems. In the most tragicomic cases, all information at a site is purely textual, but the only way of accessing it is via an imagemap menu, which does not work or works very clumsily in text-only mode. Image maps can be great for using geographic maps and other things which are inherently graphic and two-dimensional by their nature. But turning simple menus to image maps is generally counter-productive.

The following image map has been built from a screen capture of an old version of's main page, containing a menu which is colored but textual.

[ links] Home Articles FAQs Games Bulletin Boards Resources Software Books Downloads About Beta Find

If you use an imagemap, remember to include an alt attribute for the img element as well as for each area elements, and a title element for each area element. This way, assuming you use meaningful attribute values, the imagemap can be used in text-only mode too, at least on some browsers. Even done that way, there are still some special problems when you use image maps instead of links; see Tooltips and alt texts for image maps.

JavaScript pseudo-links, and links with target

Client-side scripting can be used in many ways in conjunction with links. In fact, if you wish to have a scripted event on your page, the way which works most widely is to add the onclick attribute to an a href element. But you shouldn't use that method to set up pseudo-links which work only if JavaScript is enabled.

A typical example is the most common (?) way of setting up a "link" which opens a document in a new window, a "popup" window. There is a robust way too, so there is no reason to do it so that when considered at the HTML level - which is what e.g. indexing robots do - it's a dysfunctional link with href="javascript:..." or href="#". So you can do such things right (to the extent that popup windows are right) or wrong (and the wrong way sometimes works).

One can also specify, or rather suggest, that a link be opened in a new window, or in a particular named window or frame, by using the target attribute. This is plain HTML and does not require JavaScript, but it's often used either as an alternative to JavaScript popups or in conjunction with them. Since there is a lot of misinformation about the values of this attribute, let us summarize them:

target value where the linked document will be displayed
_blank a new window, opened by the browser
_top the entire browser window, as opposite to a frame; useful for "breaking out of frames"
_parent the frameset which is the immediate parent of the current frame; "breaks out of frames" but one frameset nesting level only
_self current frame (or window); useful for overriding the effect of base target
other values beginning with underscore "_" (e.g. _new)incorrect, should be ignored by browsers (though some browsers fail to do this)
a name beginning with a letter (A-Z, a-z)the frame with that name, if existent; otherwise the window with that name, if existent; otherwise a new window, opened by the browser, and named so that when following a link with the same target value later, that window will be used for it.

Using a normal link "enhanced" with both target and onclick (with associated JavaScript code), you could set up, say, a link to so that usually it opens in a new window, and with specific properties if JavaScript is enabled. But even doing this in the technically correct way, what's the point of setting up a link which can (on most browsers) be opened only in a new window? After all, a normal link can be opened that way and in other ways <-. The most common motivation seems to be to prevent users from "leaving a site". Such attempts easily make an intelligent user leave the site!

Java pseudo-links

The Java language (which is so often confused with JavaScript) can be used to write programs which might get executed by the user's browser. And such a program, or applet, could be written so that it provides a "navigational menu". It can be written so that it works in a manner similar to image maps <- but with various animations and other mouseover effects.

A Java applet which creates pseudo-links that way can be written in a manner which degrades gracefully on browsers which do not support Java or have Java disabled. Just write the alternative menu into the content of the applet element.

"Form-based" methods: buttons and pulldown menus

For some reason, authors often wish to use buttons as links. That's technically rather simple: just write a form element where the action attribute specifies the destination address and the form content has a submit button with the desired text:

This is confusing, since a button suggests form submission, which typically means at least a dynamic query, perhaps something more serious like ordering a product. If "buttonistic" approach is combined with relying on client-side scripting, i.e. if the form is non-functional when such scripting is disabled, you've gone pretty far - from usefulness and accessibility.

Another popular way to build "navigation" is to use "pulldown menus". They normally involve more than one alternative. Example:

See the document Navigational pulldown menus HTML for a discussion of both the techniques (client-side and/or server-side scripting) as well as serious arguments against the approach. It also lists reasons why normal links are superior to such menus, and most of the reasons apply to any comparison between links and pseudo-links.

There is a special reason not to use forms in vain: form submissions can be regarded as potentially dangerous. This normally applies to forms using the post method. But a cautious user might set his browser issue a warning whenever a form is to be posted unencrypted, and he would then get a message like the following whenever he uses a "submit button link" or a "navigational menu" which works through a server-side script:

? This form is being submitted without encryption. Do you want to continue?
           OK       Cancel

"Animating" links

Link texts could be made grow big or turn green on mouseover, in some browsing situations, as discussed above. Here we shall discuss other methods which might serve the purpose of providing additional advisory information related to links. The basic idea is to let some users get extra info without following the link. You might view this as an opportunity to "advertize" the linked resources and to lure people into following the links, or you might regard it as a method to prevent people from wasting their time (and network resources) by following links which really won't give anything to them. There need not be a contradiction: by helping people to avoid links which are useless to them, you help them to make better use of those which are useful.

A basic tool for giving such extra information has been the title attribute, as explained in the alertbox we already mentioned: Using Link Titles to Help Users Predict Where They Are Going. Though widely supported by browsers, it is not ideal for usability reasons: the tooltip font size is small, and the tooltip vanishes after some seconds.

(Note: The following text is out of date; does not use the technique any more. But you can view the source of this page to get an idea of how the technique might be used.) One interesting technique is the one used at the lists of articles pages at, such as the page which lists all articles. The page contains, in addition to article names which are links to the articles themselves, a "Synopsis" (summary) and a "Techniques" (keywords) text for each article, below the article name. This of course means that the page is rather long. But using certain techniques one can make several browsers hide those texts and display them only on mouseover so that they appear in a box which covers part of the normal document content. So one gets a "tooltip" effect, which is rather flexible but requires somewhat complicated "DHTML" techniques. (That's partly outdated, too. Nowadays it just takes relatively simple code and could be implemented using just CSS.)

Discussion of "DHTML", which is actually a mixture of various techniques, is beyond the scope of this article. But if you wish to study the techniques, essential ingredients include

This approach means that no new window is created, so some of the problems of popup windows <- are avoided. On the other hand, the user cannot move the popup area to see both its content and the text covered by it. So perhaps a method which displays explanatory texts in a separate frame would be better.

Another way to create a "tooltip-like" effect in some browsing situations is to use the event attributes like onmouseover <-. And you can do this in addition to writing a title attribute.

You can use images as tooltips, if JavaScript is enabled:

Dog breeds (as per FCI classification)

  1. Sheepdogs and Cattledogs (except Swiss Cattledogs)
  2. Pinscher and Schnauzer - Molossians and Swiss Mountain- and Cattledogs
  3. Terriers
  4. Dachshunds
  5. Spitz and primitive types
  6. Scenthounds and related breeds
  7. Pointing Dogs
  8. Retrievers - Flushing Dogs - Water Dogs
  9. Companion and Toy Dogs
  10. Sighthounds

The "tooltip images" might be useful e.g. to a reader who does not quite know the English words for the breeds but recognizes breed types from images. The example above uses just basic JavaScript techniques: simple code for onmouseover event changes the image (which is initially empty, i.e. completely transparent) to a specific image, illustrating the breed, and even simpler onmouseout code switches back to the empty image.

Further reading

For other important aspects related to links in Web authoring, see especially

See also a page that extensively comments on this page: Formatting Web Links: a "Puristic" View.