There are many answers given to the questions of the form "How should I suggest that ---- links be ----?" Most of them have some serious problems in current browsers or could in future browsers. Below I explain a way that both avoids problems in existing browsers and is forward-compatible. Unlike much of the theoretical advice I give, this is intended to be usable advice when the document is complete (it's not complete yet, though). Still, use it at your own risk.
The correct way to suggest styles for links is complicated
because of both browser bugs and differences between CSS1 and
CSS2. In CSS1, there were three link pseudo-classes, all of
which were mutually exclusive:
:active. None of these
pseudo-classes applied to any elements other than links. CSS2
:visited as the link
pseudo-classes (and still mutually-exclusive), but it moved
:active into the dynamic
pseudo-classes. CSS2 also added two new dynamic
In CSS2, these dynamic-pseudo classes can match any element,
although in future versions of CSS,
:focus may be restricted to matching elements that
take user input (as defined by a CSS property).
Before I show the correct way to write selectors that match link elements, I will show a number of common mistakes:
a:link(when used to match all links)
:visitedpseudo-classes are mutually exclusive, this does not match any visited links.
aelement (as opposed to XML links).
:link, :visited, :active
:activeselector alone could match any element the user clicks on, rather than only matching links.
:hover(to match hovered links)
a:hoveris bad because it will match named anchors in addition to links.)
:hover:link, :hover:visited(to match hovered links)
a:visited, and therefore the order of the rules matters. This can be confusing, especially since MSIE is buggy and treats (some of??) them as if they had higher specificity.
The following are the best selectors to use for matching various
types of links. However, I do not advise grouping them. (By
that, I mean using a selector such as
:link:hover, :visited:hover.) Grouping could cause the
entire rule to be ignored if a browser supports one part of the
selector and not another, since browsers should ignore
the entire rule if they don't understand a part of the selector.
Furthermore, some browsers will allow only the
property to differ between links, and I haven't carefully tested
suggesting that other properties are different for different types
:visited. Rules that match only visited links should be placed after those that match unvisited links since some browsers (e.g., MacIE 4.5) incorrectly allow
:linkto match visited links.
:link, :visited. Never add other simple selectors to this that might not be recognized by a CSS1 browser, since that would force a CSS1 browser to ignore the entire ruleset.
:link:focus, :visited:focus. Because of bugs in WinIE 5.0 (and other versions), put this rule before rules that would completely override it if it instead had a selector
:link, :visited(i.e., rules with that selector or separate rules for
:link:active, :visited:active. I recommend putting this rule after the rules to match hovered and focused links so that it will override them and a link that is both active and hovered will match the active link rule (which wins according to the CSS cascading order because it is later). This may be unnessecary in some browsers that incorrectly consider one state dominant.
My demonstration document shows this method in use. (Because it suggests text-decoration, it does not show up correctly on Opera. See below.)
 This will not work on a pure CSS1 browser that supports
:active. However, I know of no such browsers. (One could match active links in such a browser with
a:active. Such a selector has the disadvantage that it could also match named anchors in CSS2 browsers.)
Here's how the following browsers will deal with the above
suggestion. Note that I haven't tested every possible
combination of things on every browser, so there may be bugs I
don't list below. If Eric Meyer's CSS
support mastergrid says that a browser doesn't support
:active, the only thing I have tested is that my
demonstration file works correctly for visited and unvisited links.
a:activeto match active links. However, all browsers that support
a:activewill handle a
borderare suggested on links. That is, if the
text-decorationproperty is given, then the text-decorations get the correct color but the text does not. However, if the
borderproperty is given, then the border gets the correct color (importantly, when the border-color is left at its default), but the text-decorations and text do not. Suggesting borders for links causes many other elements to have borders. Opera also incorrectly allows
:linkselectors to match visited links for all (?) properties except
color(others? I didn't try them all...) given in a rule with selector
:visitedwill match both visited and unvisited links.
:link:hover, etc., must be in that order, and why the rules containing
:link:focusmust come before rules that override them when they are treated as
:link. Both support
:activeonly on links (so that they are incorrectly "more important" in the cascade than
:visited). (The definition of
:activeused is somewhat strange: links match
:activewhen they have the keyboard focus (either because they are being clicked or were just clicked or because the user got to them by keyboard navigation). Netscape browsers define active links as those on which the mouse is currently depressed.)
:linkto match visited links. Other than that, it behaves just like WinIE 4.0x and 5.0.
 The demo file has not been tested on this browser.
Note (2002-08-21): this document is now cited in an article by Bill Mason, which has some updated testing results.
(Back to CSS, David Baron)
LDB, email@example.com, 1999-09-05, 1999-10-24, 1999-11-07, 1999-11-17, 2000-01-11