Skip to: site navigation/presentation
Skip to: Thoughts From Eric

Ordering the Link States

Spend 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.)

22 Responses»

    • #1
    • Comment
    • Mon 4 Jun 2007
    • 2226
    thacker wrote in to say...


    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.

    • #2
    • Comment
    • Mon 4 Jun 2007
    • 2231
    Aristotle Pagaltzis wrote in to say...

    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”.

    • #3
    • Comment
    • Mon 4 Jun 2007
    • 2255
    Philippe wrote in to say...

    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.

    • #4
    • Comment
    • Mon 4 Jun 2007
    • 2310
    John B wrote in to say...

    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.

    • #5
    • Comment
    • Tue 5 Jun 2007
    • 0046
    Bill Mason wrote in to say...

    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.

    • #6
    • Comment
    • Tue 5 Jun 2007
    • 0141
    Tommy Olsson wrote in to say...

    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.

    • #7
    • Comment
    • Tue 5 Jun 2007
    • 0337
    Estelle wrote in to say...

    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.

    • #8
    • Comment
    • Tue 5 Jun 2007
    • 0758
    F.O.R. wrote in to say...

    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.

    • #9
    • Comment
    • Tue 5 Jun 2007
    • 0800
    Sebastian Redl wrote in to say...

    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.

    • #10
    • Comment
    • Tue 5 Jun 2007
    • 1255
    Patrick Lee wrote in to say...

    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.

    • #11
    • Comment
    • Tue 5 Jun 2007
    • 1616
    Patrick Lee wrote in to say...

    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.

    • #12
    • Comment
    • Tue 5 Jun 2007
    • 1817
    patrick h. lauke wrote in to say...

    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…

    • #13
    • Comment
    • Wed 6 Jun 2007
    • 1432
    Jens Meiert wrote in to say...

    “:link, :visited, :focus, :hover, :active” should be the most useful way […].

    • #14
    • Comment
    • Sat 9 Jun 2007
    • 1820
    thacker wrote in to say...

    Still waiting for Meyer’s analysis and reasoning on the questions that he presented.

    • #15
    • Comment
    • Sun 10 Jun 2007
    • 1105
    GangRel wrote in to say...

    i think hover should overrule focus (lvfha)

    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).

    • #16
    • Pingback
    • Mon 11 Jun 2007
    • 1935
    • #17
    • Comment
    • Mon 11 Jun 2007
    • 2051
    Mike Cherim wrote in to say...

    I place a:focus before a:active — in the typical order of use.

    • #18
    • Comment
    • Tue 12 Jun 2007
    • 0155
    David Hucklesby wrote in to say...

    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.

    • #19
    • Comment
    • Mon 18 Jun 2007
    • 0425
    Stumpy wrote in to say...

    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.


    • #20
    • Comment
    • Fri 29 Jun 2007
    • 0349
    Gerrit van Aaken wrote in to say...

    I”m with Jens. My favourite rule is “Lord Vader”s Former Handle Anakin”.

    • #21
    • Pingback
    • Wed 28 Jan 2009
    • 0134
    Received from 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: […]

    • #22
    • Pingback
    • Wed 23 Jun 2010
    • 1439
    Received from 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 […]

Leave a Comment

Line and paragraph breaks automatic, e-mail address required but never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Remember to encode character entities if you're posting markup examples! Management reserves the right to edit or remove any comment—especially those that are abusive, irrelevant to the topic at hand, or made by anonymous posters—although honestly, most edits are a matter of fixing mangled markup. Thus the note about encoding your entities. If you're satisfied with what you've written, then go ahead...

June 2007
May July