Ordering the Link States
Published 17 years, 4 months pastSpend any time at all writing above-beginner CSS, and you’re going to come across the “link-visited-hover-active” (LVHA) rule. This holds that the four link states should always be listed in that order, like so:
a:link {color: blue;} a:visited {color: purple;} a:hover {color: red;} a:active {color: yellow;}
Masters of the dark arts of specificity know why this rule exists and how it does or doesn’t apply, but if you’re still a padawan in these matters (or just rusty), you can get a quick refresher from this old chestnut of mine.
Now, it’s the case that this will become less of an issue over time becuase IE7 supports (and one presumes future versions of IE will continue to support) chained pseudo-classes, like a:link:hover {color: red;}
. Once you start chaining those you transcend a lot of the specificity-ordering concerns that drive the LVHA rule. However, we’re not there yet.
Which brings me to the point of all this: the fifth possible link state, :focus
. Assuming we’re going to avoid chaining pseudo-classes for a while yet, but that we want to introduce link-focus styles, where should it fit in the ordering? For the purposes of this discussion, assume the following:
a:focus {color: orange;} a:link {color: blue;} a:visited {color: purple;} a:hover {color: red;} a:active {color: yellow;}
We need to move the a:focus
rule so it has a visible effect. But where? Should it come before a:hover
, after a:hover
, or after a:active
? In other words, which states’ styles should the focus style overwrite?
I’d like to hear your thoughts on the matter, and especially the rationale driving your answer. Accessibility experts are particularly welcome to weigh in, but it’s anyone’s game here.
(Postscript: I know that many problems can be avoided by picking a different styling effect for the focus style, like a border or outline, or boldfacing or italicizing the text of a focused link. Still, some people will want to handle everything through color, regardless of the problems this can cause for the colorblind or images-as-links, and I’d like to address that specific situation. Thanks.)
Comments (22)
Meyer–
My take on pseudo link states is several fold .. keep in mind that I consider myself to be an expert in nothing.
The focus element should follow the hover rule in the LVHA priority. My reasoning is that most modern accessibility user agents will read and respond to the hover state and therefore, ignore the focus state. This includes human interface devices that are supported by these user agents. Naturally, color, as you mentioned, is important. I try to take screen shots of the basic design, including both hover and link effects, and check the color against deuteranope, protanope and tritanope forms of color-blindness. The same applies to all images.
Older assistive technology user agents fall back onto the focus style, including the safest and most secure browser available, the Lynx Text Only browser. Most of these user agents are configurable by the user on how color is handled and is user configurable for color.
For traditional uses [mouse blowouts, cordless keyboard navigation] and for device independent use of the focus styles, I generally use a border effect for any link, including hover effects of images used as links. As stated, color is checked for the three basic types of color blindness to insure sufficient contrast.
Another issue that I try to be sure is sufficiently compensated are muscular control issues, e.g. Parkinsons Disease. Hover styles include padding specifications so that the hover area is of sufficient size to compensate for muscular control issues. It also aids traditional users when the mouse starts acting weird.
Thanks for a very interesting topic. Am looking forward to what others have to say including yourself.
A link that”s active is in the process of being followed; none of the other states matter, so it takes highest precedence.
A focused link is also usually indicated in some way by the browser (using a selection rectangle, commonly), whereas a hovered-over link has no such default presentation, so I would argue that hover takes precedence.
It”s interesting that you slipped in the “padawan” term, because Andrew Krespanis proposed a great mnemonic for the order (see slide 12): “Lord Vader”s Former Handle, Anakin”.
a:active should come last (clicking the link also give it focus). :focus should follow :link and :visited. :focus and :hover are sort mutually exclusive states, although I’d put :focus first, followed by :hover.
When a keyboard user accesses the link, :hover doesn’t matter (she won’t see the hover). When a mouse-user (or other pointing device) accesses the link (move pointer over link: – :hover, then click – :active), then hits the back button, a well-behaved browser will still have the link in a focussed state. If :hover comes before :focus the mouse user won’t see the hover effect anymore.
Of course, all this doesn’t matter to IE, as it doesn’t understand anything about :focus.
I was debating in my head between putting :focus before or after :hover, but after reading Philippe’s comment I think he has it right. :focus before :hover, and :active, but after :link and :visited.
Personally, I just write them this way and :focus works fine in browsers that support it:
:link:focus, :visited:focus {color: orange;}
:link {color: blue;}
:visited {color: purple;}
:link:hover, :visited:hover {color: red;}
:link:active, :visited:active {color: yellow;}
I wrote this up once based on some notes from David Baron.
It depends on the desired behaviour. I think putting
:focus
before:hover
makes sense. That way, you’d get focus styling on both visited and unvisisted links, and you’d still get a visual cue when hovering over a link with focus.On the other hand, I normally apply very different styling to
:focus
; often a distinctive background colour to make it attract the user’s attention anywhere on the page. My:hover
styling is more subtle, since the user will already be looking in the right place. If those two aren’t compatible, I’d put:focus
after:hover
.I agree with Thacker that the focus element should follow the hover rule in the link – visited/ hover / (focus)/ active (LVH(F)A) priority list. This order enables the
:focus
and:hover
states to both be visible as appropriate in browsers that support the:focus
pseudo-class. I did debate placing the:focus
state before the:hover
state since mouse action is the default expected activity for web sites, but alternative technologies, especially cell phones, are more likely to use keyboard or keyboard-like navigation. My cell battery is dead, so I can’t test my theory yet, but I realize that if my cell phone, like IE, does not support:focus
, then, like IE, it will ignore it, so i go back to agreeing with Thacker.For those using the keyboard to navigate, the
:focus
effect will be visible when tabbed, when a mouse user would normally get:hover
. This:focus
display can be identical to the:hover
look to give the keyboard user the same visual experience as the mouse user. The:hover
and:focus
states should differ enough from the other states of:link
,:visited
and:active
to provide the keyboard and mouse users with enough visual cues to inform the user which link has focus and/or is being hovered. The:hover
state (and therefore all states) must provide enough padding for the less dexterous to be able to click in the active area.When declaring
:focus
to be relatively very different from the mouse effects so that the keyboard user has strong visual cues as to the current focus,:focus
should be declared after:hover
. If, on the other hand,:focus
and:hover
are going to be the exact same, then they should be declared together and precedence between the two doesn’t matter.Note that padding that is included on
:focus
and:hover
states should be included on all link states to ensure that the content doesn”t move or jump when changing states.Here’s my take:
a:link {color: blue;}
a:visited {color: purple;}
a:hover {color: red;}
a:focus {color: orange;}
a:active {color: yellow;}
In other words, focus -for an anchor- fits between the active and hover states. The rationale is that I see ‘focus’ as something you do right before interacting with an element.
Thus, I give focus to a textbox before I can type in it, to a button before I can click it. Anchors seem to fit the same pattern. So, hover and focus feel like they should be related, and focus and active too, since typing in a textbox, or clicking a button is what I do with them right after I gave them focus.
At least that’s my story until I get more coffee.
F.O.R.
I’ll join the consensus and say order focus between visited and hover, but I’ll take a different line of reasoning.
The most transient pseudo-class is active. It applies only during the brief time the user holds down the mouse button. Therefore it is the last. As it lasts only a short time, it should override everything else.
The most permanent class is link. It applies to any link. Therefore, it cannot override anything else, it must be the first.
Visited is next after link. It doesn’t apply to all links, but it applies irregardless of current user activity; instead it depends on past user activity. Once visited applies, only time or a history purge will make it not apply.
So the question remains of the relative order of focus and hover. I’d say that the mouse, which causes hovering, is quicker-moving than the keyboard focus, so hover is the more transient state and is ordered later.
I’m going to stick with LVFHA because I’ve always used Las Vegas Future Homemakers of America to remember the order. Unless of course you discover some compelling reason why I should change this order and think of a new mnemonic.
Actually, that’s not quite right. I’ve used Las Vegas Federal Housing Authority to remember LVFHA. Fits better with Sin City’s recent growth.
off topic a bit, but: an interesting usability enhancement that i recently implemented on a site – style visited links on focus/hover differently from unvisited links on focus/hover…
“:link, :visited, :focus, :hover, :active” should be the most useful way […].
Still waiting for Meyer’s analysis and reasoning on the questions that he presented.
i think hover should overrule focus (lvfha)
Reasoning:
They only collide, when a mouse-user points on a focused link. at that point the user either knows that the link has focus (he saw it before hovering) or he doesnt care about it having focus. In contrast, all reasons for showing him a hover-effect to reflect his action still apply, since he obviously wants to click and not hit return to open the link.
The lvhfa argument “clicking a button is what I do with them right after I gave them focus” does not feel correct to me, since this “giving focus” is just a sideeffect of clicking/activating and not really user-intended (unlike with textfields), which will make the active:-rule instantly overwrite the focus:-rule anyway (if we stay with the example of just different colors).
Pingback ::
Max Design - standards based web design, development and training » Some links for light reading (12/6/07)
[…] Ordering the Link States […]
I place
a:focus
beforea:active
— in the typical order of use.I hope we can get this sorted. Using :focus in the middle or at the beginning works to provide keyboard users with pop-up (spanned) images. But attempting to use :active for IE users gives problems– the :hover does not work well because the :active state “sticks”.
Ever the optimist, I hope there is a CSS solution to this.
I remember reading something a few years ago that used this piece of wisdom to remember the order:
[L]uther [V]andross [F]ans [H]ate [A]bba.
Brilliant.
I”m with Jens. My favourite rule is “Lord Vader”s Former Handle Anakin”.
Pingback ::
CSS Code Snippets : 15 Wicked Tricks | DevSnippets
[…] Eric Meyer explains why the order matters. So in case you came across the “link-visited-hover-active” (LVHA) rule. This holds that the four link states should always be listed in that order, like so: […]
Pingback ::
BUUP • the most reckless compilation of preposterous rants » Ten CSS tips designers should know or learn
[…] 10. link-visited-hover-active (LVHA) rule Masters of the dark arts of specificity know why this rule exists and how it does or doesn’t apply, but if you’re still a padawan in these matters (or just rusty), you can get a quick refresher from this old chestnut of mine. — by Eric Meyer […]