Is there a reason to use a instead of a:link or a:visited in my stylesheet?

css, css-selectors, html

Solution

This is of course assuming there would never be a reason to use an `<a>` tag without an `href` value. Maybe that's a mistaken assumption.

It depends on your project. Strictly speaking, that is a mistaken assumption, as not every `<a>` element needs to have a `href` attribute. Indeed, it's still not required in HTML5 to specify `href` for every `<a>`. Chris Blake and Ryan P mention named anchors, and I'll add that while the `name` attribute for `<a>` has been made obsolete as of HTML5, named anchors are still rife and will continue to be, simply by legacy and tradition.

That said, going forward, authors are recommended to use `id` attributes and not named anchors to designate document anchor fragments.

Also, `<a>` elements that lack `href` attributes but have `onclick` attributes for JavaScript are a mess. Even if you insist on using `onclick` to bind events, for the sake of graceful degradation you should at least point it somewhere using `href`.

But to make things simple, let's assume that you won't be writing `<a>` elements without `href` attributes.

With this in mind, going back to the CSS selectors, there are two important points to consider:

Are they the same?

No, the selectors `a` and `a:link, a:visited` are not strictly equivalent. I'll quote a previous answer of mine on this topic:

The selector `a` should match any `<a>` elements, while `a:link` only matches `<a>` elements that are unvisited hyperlinks (the HTML 4 document type defines hyperlinks as `<a>` elements with a `href` attribute). Nowhere does it state in either specification that `a` should automatically translate to `a:link` or vice versa.

In other words, in HTML, `a:link, a:visited` (in CSS1) is strictly equivalent to `a[href]` (in CSS2 with an attribute selector) or `a:any-link` (new in Selectors level 4), rather than `a`. Note that it doesn't matter whether the attribute has a value or not, as long as it is present the pseudo-classes will match, hence `[href]`. Note also that this is true for all current standards of HTML, and I believe this includes HTML5, since as mentioned above `href` is not a required attribute in any existing spec.

Just bear in mind, that other languages may define completely different semantics for `:link` and `:visited` — it just so happens that they coincide with an equally specific selector in HTML, which is covered next...

Specificity

This is a huge gotcha: `a` is less specific than either `a:link` or `a:visited`, which is a very common source of specificity problems that are particularly evident when applying styles to `a`, `a:link` and `a:visited` separately. This then leads to all kinds of `!important` hacks to get around a lack of understanding of specificity.

For example, consider this CSS:

/* All unvisited links should be red */
a:link {
    color: red;
}

/* All visited links should be slightly darker */
a:visited {
    color: maroon;
}

/* But no matter what, header links must be white at all times! */
body > header > a {
    color: white;
}

This doesn't work as expected, because `a:link` and `a:visited` (what I call generalized rules/selectors) are more specific than `body > header > a` (what I call a specialized rule/selector), so header links will in fact never be white:

/* 1 pseudo-class, 1 type  -> specificity = (0,1,1) */
a:link, a:visited

/* 3 types                 -> specificity = (0,0,3) */
body > header > a

Now the first thing that comes to mind for most CSS coders is to throw in `!important`, trumping specificity altogether:

body > header > a {
    color: white !important;
}

But that gets you all kinds of bad rep, right? So let's not do that.

Selectors level 4 gives you not one, but two solutions to this specificity problem. These solutions, new as they are, aren't supported in Internet Explorer and Microsoft Edge Legacy (the UWP/EdgeHTML/not-Chromium one), but thankfully there is a third solution that works in Internet Explorer 7 and later, which is `a[href]`, the attribute selector I mentioned above.

1. The `:any-link` pseudo-class

`:any-link` has some history behind it which you can read in my answer to this question, but practically speaking, `:any-link` serves as a catch-all for `:link, :visited`. Its main purpose is to eliminate selector duplication, and for that reason there is in fact an equivalent in the form of `:is(:link, :visited)`.

You can use `a:any-link` in your specialized rule to match the specificity of the generalized `a:link` and `a:visited` rules, thereby allowing it to override them:

a:link {
    color: red;
}

a:visited {
    color: maroon;
}

/* 1 pseudo-class, 3 types -> specificity = (0,1,3) */
body > header > a:any-link {
    color: white;
}

2. The `:where()` pseudo-class

`:where()` also has some history behind it, but essentially it's an analogue to `:is()` with the exception that it zeroes out the specificity of its argument. See my answer to this question for an in-depth guide to how it works.

You can wrap the `:link` and `:visited` pseudo-classes in `:where()`s to remove their pseudo-class specificity, thereby allowing them to be overridden by the specialized rule:

/* 1 type                  -> specificity = (0,0,1) */
a:where(:link) {
    color: red;
}

/* 1 type                  -> specificity = (0,0,1) */
a:where(:visited) {
    color: maroon;
}

/* 3 types                 -> specificity = (0,0,3) */
body > header > a {
    color: white;
}

3. `a[href]` (for older browsers)

Fortunately, if you need to support older browsers, an attribute selector is as specific as a pseudo-class. This means you can use `a[href]` to mean both/either `a:link` and/or `a:visited`, and not run into specificity issues because they are equally specific!

/* 1 attribute, 3 types    -> specificity = (0,1,3) */
body > header > a[href] {
    color: white;
}

So which selector(s) to use?

This is all still incredibly subjective, but I follow these personal rules of thumb:

Apply to `a` styles that do not depend on the state of a link (i.e. as long as it's a link will do).

Apply to `a:link` and `a:visited` styles where it does matter whether a link is visited or not.

Taking into account the specificity problems mentioned above, do not mix any declarations between both `a` and `a:link`/`a:visited` rules. If I need to apply the same property to both states somewhere, but I already have it in separate `a:link` and `a:visited` rules, I'll use one of the 3 options above to avoid specificity problems.

For example, here are the link styles I used in my site's Coming Soon page prior to its launch:

a {
    text-decoration: none;
    transition: text-shadow 0.15s linear;
}

a:link {
    color: rgb(119, 255, 221);
}

a:visited {
    color: rgb(68, 204, 170);
}

a:hover, a:active {
    text-shadow: 0 0 0.5em currentColor;
}

a:focus {
    outline: thin dotted;
}

/* ... */

footer a:link, footer a:visited {
    color: rgb(71, 173, 153);
}

The `text-shadow` transition is defined for all `a` elements, regardless of whether they are visited or not, because the transition only takes effect when one of them is moused over and clicked (corresponding to the `a:hover, a:active` rule).

Now, I want visited links to have a slightly darker shade than unvisited links, so I put the colors in separate `a:link` and `a:visited` rules. However, for some reason, I want footer links to appear the same color whether they're visited or not.

If I use `footer a`, I'll run into the specificity problems described above, so I choose `footer a:link, footer a:visited` instead. This was for legacy reasons (as you'll see below, I originally posted this in 2012!), but of course it can be shortened to `footer a:any-link`. However, the specificity-matching principle applies all the same.

Hopefully my advice helps you get a handle on the mess that is link styles.

Problem

Original source

Related problems

• What's the :any-link pseudo-class for?
• What is the difference between :where() and :is()?