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

Looking For Focus

In the reset revision draft I posted Monday, I got tripped up by some last-minute changes and I’m going to think out loud (so to speak, as it were) about possible solutions.

The problem is that the presence of a in the first rule means that focus outlines on hyperlinks are removed.  Thus in commenting out the :focus rule I restored default focus styles to form elements, but not hyperlinks.  This wasn’t a problem up until roughly a day before I published, but last-minute tinkering brought it back.  I’d say that’ll teach me not to tinker, but I hate to lie.

I’ve come up with the following solutions.  Consider them as mutually exclusive.

  • Remove a from the first rule.  This would exempt it from being reset at all.  On the one hand, this means that focus defaults are restored.  On the other hand, by exempting an (incredibly pervasive) element from the list, it does violate the spirit of element agnosticism I try to follow.  On the gripping hand, that first rule doesn’t do much to reset links as it is: their text-decoration and color properties are not altered.  Back in 2007 the color would have been thanks to a color: inherit declaration, but that was dropped at the time and I don’t think it’s likely to return.  Even if it does, the question of exempting a would remain and possibly even deepen.

  • Remove outline: 0 from the first rule.  The only things I can think of that get outlines are focused form elements, which the reset doesn’t touch; and focused hyperlinks, which I’m trying to avoid touching in the first place.  That’s not very forward-looking, though.  Outlines could start showing up in future browsers or on future elements.

  • Define explicit a:focus styles, as the HTML5 Doctor reset does.  This overcomes the problem of focus-stripping, but imposes a specific focus appearance.  That violates the entire spirit of the reset.  Of course, it’s not as though there’s much variance in how browsers present link focusing, and it’s pretty easy to write a rule that would be mistaken for browser defaults by just about anyone.

In the process of writing this out, I think I’ve mostly settled on which choice I prefer, but I’d like to hear what you think.  Which option strikes you as best, and why?

51 Responses»

    • #1
    • Comment
    • Wed 5 Jan 2011
    • 1017
    Russell Bishop wrote in to say...

    I’d go for the 3rd option. I think if you feel it’s that important for people to always remember :focus styles, then you should add one in for them (very simple, obvious and commented) for people to edit (as opposed to removing it).

    • #2
    • Comment
    • Wed 5 Jan 2011
    • 1020
    David Moffitt wrote in to say...

    I would say your first option, remove A from the rule makes the most sense – even if, as you said, it violates the spirit of being element-agnostic, it’s probably best functionally.

    • #3
    • Comment
    • Wed 5 Jan 2011
    • 1031
    CoolGoose wrote in to say...

    I would say 3rd as well. I often forget about defining and testing :focus

    • #4
    • Comment
    • Wed 5 Jan 2011
    • 1031
    Steven wrote in to say...

    Honestly as a Designer and Developer I prefer resets give me a clean slate, rather then impose one. That being said if I had to choose one of your methods I would prefer the third option of Defining an explicit a:focus, that way its easy to comment out or remove.

    • #5
    • Comment
    • Wed 5 Jan 2011
    • 1034
    Pete Hau wrote in to say...

    As I see it, the purpose of reset.css is to provide a standardised, intuitive but still-usable set of default styles across all elements. The 3rd option achieves that purpose.

    • #6
    • Comment
    • Wed 5 Jan 2011
    • 1041
    Kristofer Layon wrote in to say...

    You might argue that this unique nature of :focus cuts you some slack, and gives you enough reason to make an exception to your element agnosticism. Simply put, you’re forced into a situation where pure principle is not adequate. So with this stance, it seems easier to justify Option 1 than it does to define an appearance in a reset, which is not merely a different exception but a somewhat ironic one.

    BTW: I love it when the Web enter philosophical territory. Art, science, and craft indeed. Carry on, sir!

    • #7
    • Comment
    • Wed 5 Jan 2011
    • 1041
    Blain Smith wrote in to say...

    I agree with Russell, but uncommented and just reset it to something basic (outline: thin solid gray;). When people see it in action they will also be reminded to set it themselves, but at least it is something useable by default.

    The point of your reset is to level the playing field across browsers for a starting point so this does it just fine.

    Of course you could go the other route and go crazy to force people to change it (outline: thick dashed pink;) haha. That’ll make me focus on setting my own styles…pun intended.

    • #8
    • Comment
    • Wed 5 Jan 2011
    • 1049
    Rich Clark wrote in to say...

    As the author of option 3, needless to say I’m going to stick with that approach. The reason for this being as I think Eric explained with his original reset that it’s to be used as a starting point and should be customised on a case by case basis. Therefore simply style focus accordingly per project, job done.

    • #9
    • Comment
    • Wed 5 Jan 2011
    • 1052
    Barney wrote in to say...

    You should reset the outline to nothing, as in the draft.

    Making an exception of it is acceding to a dubious political argument that should really take place outside of your work on reset, which has come to be known as an extremely thorough utility of entirely practical functionality, very plainly defined by its title.

    Taking any of the options you just mentioned would be to the detriment of the description I gave. It adds a “except for this bit, because actually it’s very important and you’ll probably forget to put it back in”.

    I appreciate that in all probability, thousands upon thousands of people would download your new version, still forget to re-specify link focus styles, and leave the world in a situation whereby according to selective causal logic, YOU are to blame for the awful accessibility restrictions the web over — it’s just that, personally, I believe the way to address that problem is for front-enders to become more educated, conscientious and responsible for their own work.

    If you do decide to make this exception, I strongly advise against option 3: the notion that people will be including your reset, reseting the outline again, and then redefining focus styles later, is a criticism that reset.css really doesn’t deserve to face. Besides, making a creative decision about THE best way to identify focussed elements is a whole other kettle of fish. The browser vendors have their ideas — if people believe in those, they don’t believe in resets. Asserting your ideas about the ultimate technical solution to an accessibility design decision is really not in the purview of what this started off as.

    • #10
    • Comment
    • Wed 5 Jan 2011
    • 1055
    jackson wrote in to say...

    As far as i can tell opt 3 would be the best choice to fix this issue

    • #11
    • Comment
    • Wed 5 Jan 2011
    • 1056
    kikito wrote in to say...

    I enjoy philosophy like anyone else. My favorite philosophy school is pragmatism – as in “When in doubt, pick the thing that works”.

    Hence I vote for number 3.

    • #12
    • Comment
    • Wed 5 Jan 2011
    • 1120
    Eric Meyer wrote in to say...

    So far that’s eight votes for option 3, two votes for option 1, and one vote for “none of the above”. Interesting! I expected more of a mix.

    • #13
    • Pingback
    • Wed 5 Jan 2011
    • 1122
    Received from WebAIM: Blog - Progress on Focus Indicators

    […] As noted in the original article, many of these sites use a CSS reset file that removes the focus indicator. One of the most popular of these reset files is Eric Meyer’s reset.css. In a recent update to reset.css, Eric has now commented out the line that removes focus indicators, thus requiring author intervention to re-enable it. UPDATE: Today Eric posted some thoughts about how best to address this. […]

    • #14
    • Comment
    • Wed 5 Jan 2011
    • 1129
    Jared Smith wrote in to say...


    Thank you for addressing this. Outline is becoming common on elements besides links and form controls, particularly with scripted interactive elements and on elements with tabindex values of 0 or -1 (0 puts the element in the keyboard tab order and -1 allows it to be focused with scripting).

    I don’t see any accessibility issues with any of these approaches, but Option 3 would provide the most accessible default.

    • #15
    • Comment
    • Wed 5 Jan 2011
    • 1131
    Andrew Assarattanakul wrote in to say...

    I feel option 2 is the best solution.

    The outline:0 really only affects the anchor tag at the moment and those who know enough to define the outline can redefine it on their own. This will take care of those who drop the reset in as they already have with the previous version.

    If outlines start appearing on other elements then I would worry about it when it happens and update the reset css accordingly.

    • #16
    • Comment
    • Wed 5 Jan 2011
    • 1152
    David Baron wrote in to say...

    I’d go for option 2; the outline property is basically intended only for indicating focus, and I’d be surprised if UA style sheets used it for anything other than as a focus indicator.

    • #17
    • Comment
    • Wed 5 Jan 2011
    • 1155
    Matt wrote in to say...

    Option 3. If the designer wants an entirely clean slate all they have to do is comment out that one line and the designers that are in a rush will not be without a focus rule.

    • #18
    • Comment
    • Wed 5 Jan 2011
    • 1201
    Ross Olson wrote in to say...

    Voting for Option 2.

    It really is in the best spirit. The Reset CSS is used over and over again as a library. Option 3 means that we can’t use it as a static library. If outline isn’t doing anything in the first block, then why add it?

    In 4 years, you can revisit this and see if Outline becomes rendered so differently by various browsers that it needs to be tamed. At this point, we’re seeing browsers render these elements in a MORE uniform way, not less (excepting device-specific rendering needs, e.g. desktop/tablet/phone). Don’t fix a problem that doesn’t exist yet.

    • #19
    • Comment
    • Wed 5 Jan 2011
    • 1207
    AlastairC wrote in to say...

    Interestingly, the box I’m typing into has a yellow outline in chrome, so I’m not sure that it would be that easy to write a short, cross-browser equivalent.

    Given that I’d lean towards 2, but anything that means outline is not automatically removed is better for keyboard users.

    • #20
    • Comment
    • Wed 5 Jan 2011
    • 1240
    Patrick H. Lauke wrote in to say...

    My own preference would be for option 2, as arguably outline doesn’t affect layout inconsistencies etc that your reset originally wanted to tackle. but I could live with 3.

    However, you note that “it’s not as though there’s much variance in how browsers present link focusing” – I don’t quite agree. IE and Firefox do the dotted line thing, while Chrome, Safari and Opera all do their idiosyncratic colour/glow outlines. Still, as long as your choice for focus style to be included in your reset is fairly obvious, it should be fine. Incidentally, I revisited my own old experimentations in this field, and was pleasantly surprised by a few bugs that were fixed in Opera (which now make 3 a viable solution) – see the revised Better CSS outline suppression page.

    • #21
    • Comment
    • Wed 5 Jan 2011
    • 1244
    Eric Meyer wrote in to say...

    Looks like option 2 is staging a rally!

    Now at ten votes for #3, five votes for #2, and two votes for #1 (plus one “NOTA”).

    • #22
    • Comment
    • Wed 5 Jan 2011
    • 1303
    Roger Johansson wrote in to say...

    Here’s another vote for #2.

    • #23
    • Comment
    • Wed 5 Jan 2011
    • 1311
    Bridget Stewart wrote in to say...

    I’m leaning toward option 2.

    I understand that it appears to be less than forward-thinking, but I agree with another commenter that it might be trying to solve a problem that doesn’t yet exist.

    If outlines begin appearing on lots of elements in the future, I would be concerned at that point that the reset stylesheet needs to be revisited. No need to think about removing a potential nuisance that isn’t yet a nuisance.

    To me, that seems like suspending a kid from school because he might end up being disruptive – before he has a chance to actually disrupt anything. :)

    As for option 3, it seems like an odd task in a reset to both remove and reapply styles for a particular element. I think the defaults for focus on forms and elements aren’t nearly as disruptive to layouts and design as other things being reset once were. But maybe that’s just me. Maybe the defaults aren’t as “stylish” in terms of the overall design, but like anything – they can be altered.

    Yeah, with all that rambling – I still vote for option number 2.

    • #24
    • Comment
    • Wed 5 Jan 2011
    • 1313
    Bridget Stewart wrote in to say...

    The above comment should have read “defaults for focus on forms and anchor elements” — boooooo on my typing skills!

    • #25
    • Comment
    • Wed 5 Jan 2011
    • 1323
    Tracy Rotton wrote in to say...

    Putting my hand up for option 2. People can always add their own to reset to it if they’d like, and if they don’t that means the browser default isn’t bothering them much.

    I used to reset :focus all the time until I learned about the accessibility (and usability) impact. In my own version of your reset, which I use as more of a baseline and includes font stacks, paragraph spacing, etc., I’ll probably define :focus to at least look uniform across browsers.

    • #26
    • Comment
    • Wed 5 Jan 2011
    • 1352
    Tim Arnold wrote in to say...

    I’m also going to vote for #3 as it seems in the spirit of the reset for :focus to be uniform across all browsers. The purpose of the reset is not, as I understand it, to remove any and all styles from any and all HTML, but rather to start all off on a common ground. If I’m reading correctly #3 accomplishes this better than simply removing the outline entirely and leaving it up to each browser to implement as they see fit.

    • #27
    • Comment
    • Wed 5 Jan 2011
    • 1444
    Pies wrote in to say...

    “That’s not very forward-looking, though. Outlines could start showing up in future browsers or on future elements.”

    Don’t fix the problems you don’t have. Anything could happen in future browsers.

    • #28
    • Comment
    • Wed 5 Jan 2011
    • 1508
    Jarrod wrote in to say...

    Another vote for number 2.
    As previously stated, outline doesn’t create any layout inconsistencies. Furthermore, it allows the naive user to experience their browser as expected across most of the rest of the web.

    • #29
    • Comment
    • Wed 5 Jan 2011
    • 1535
    Tim Buchheim wrote in to say...

    I’d go with #2 personally. Outlines don’t cause layout problems, and I’d assume a browser would probably have a good reason (eg. accessibility) for adding them.

    • #30
    • Comment
    • Wed 5 Jan 2011
    • 1553
    Jonathan Snook wrote in to say...

    I vote for number #2.

    • #31
    • Comment
    • Wed 5 Jan 2011
    • 1625
    William wrote in to say...

    Option 2: Remove outline from the first rule; the reset is to fix the past, not the future.


    Option 3: Also, define explicit a:focus styles. An outline is 1px dotted in IE and Firefox; 5px auto in WebKit, yellow in Chrome and blue with rounded corners and opacity in Safari; and then there’s Opera its pseudo-Safari approach.

    • #32
    • Comment
    • Wed 5 Jan 2011
    • 1643
    James Sumners wrote in to say...

    I vote for option #3. Highlighting links with an outline by default makes sense (as it is most prevalent). I suppose that if you want to draw attention to the “reset” then you could make the outline color very obvious. Maybe #F0F.

    • #33
    • Comment
    • Wed 5 Jan 2011
    • 1646
    Anthony Bosio wrote in to say...

    I vote for keeping the reset as imposing a clean slate but including a concise list in a comment of all the properties someone needs to remember to specify on their own.

    I think that might be “none of the above”.

    • #34
    • Comment
    • Wed 5 Jan 2011
    • 1746
    Peter Wilson wrote in to say...

    Option 2 – Forward compatibility will always be a problem, as seen with the elements introduced in HTML 5.

    • #35
    • Comment
    • Thu 6 Jan 2011
    • 0229
    JulienW wrote in to say...

    I’d prefer option 3.

    BTW I had a “good” time finding how to disable default ‘invalid’ styles for html5 forms with native validation, it might be a good idea to include these reset styles as well.


    • #36
    • Comment
    • Thu 6 Jan 2011
    • 0738
    Mitică U. wrote in to say...

    Option 2 definitely.

    Being that CSS reset should be a general solution, those particular cases you have to handle by hand each time, when opting for #3, sounds like an ostricho-camel funny to me.

    Even more, opting #2 means maintaining accesability, which was the point, to start with.

    • #37
    • Comment
    • Thu 6 Jan 2011
    • 1140
    Eric Meyer wrote in to say...

    After a day of voting, we now have a new leader with 13 votes for option 2, 12 votes for option 3, two votes for option 1, and two votes for “none of the above”. Wow! That was quite a swing in the results.

    • #38
    • Comment
    • Thu 6 Jan 2011
    • 1330
    Ross Olson wrote in to say...

    Eric, at the top of the CSS Reset page, you wrote:

    The goal of a reset stylesheet is to reduce browser inconsistencies in things like default line heights, margins and font sizes of headings, and so on.

    I think you should clarify the “and so on” because that will really point us in the direction you’re expecting this to go. The list of items you wrote out here all impact the layout of a page and the flow of the text. The conservative interpretation here is that CSS Reset was meant to prevent the trainwreckedness of page layouts that were caused by differing default renderings.

    However you’ve included outline, background, and text-decoration attributes, each of which don’t have an impact on page layout. So you were thinking somewhat beyond just page layout/element positioning. But how far? I would say you should have a specific vision for what CSS Reset should be doing for these three attributes.

    I can make the argument that resetting background is a good move for consistent rendering of initial page layouts, so I would add that to your first sentence on the CSS Reset page and keep it in the CSS Reset code.

    I cannot make a good argument for resetting INS/DEL’s text-decoration since I’ve never used those in a production environment. I have nearly always removed these from my use of your code.

    I cannot make a good argument for resetting outline because I’ve never seen the variation in outline rendering cause problems in my pages. (Nor anyone else’s for that matter.) This is why I voted for Option 2 previously.

    And here we have the crux of the issue: is CSS Reset meant to [A] fix the problem of seriously broken layouts due to inconsistent browser defaults or [B] is it meant to ‘clean slate’ all aspects of browser rendering?

    I hope you think that [A] is the better way to go here, because [B] implies that the Web Designer knows the very best way to override the local needs of a browser without knowing the context of the user (keyboard or no, mouse/trackball or no, touchscreen or no, etc.).

    TL/DR: Get rid of the Outline attribute because it’s not a problem that needs fixing.

    • #39
    • Comment
    • Thu 6 Jan 2011
    • 1336
    Eric Meyer wrote in to say...

    It’s a bit more [B] than [A], Ross, though neither is fully realizable given the tools at our disposal.

    • #40
    • Comment
    • Thu 6 Jan 2011
    • 1344
    Cogito wrote in to say...

    Definitely option three, you do your part and leave it up to the discerning (we hope) web designers that will be using it.

    Though option two looks good, too. That could be equally as helpful, and on the matter of focusable elements turning up in the future, you’ve changed the reset before, wouldn’t be that big of a deal to do it again. ;)

    • #41
    • Comment
    • Thu 6 Jan 2011
    • 1450
    Ross Olson wrote in to say...

    If it is more [B] then why aren’t form elements dealt with?

    • #42
    • Comment
    • Thu 6 Jan 2011
    • 1736
    Eric Meyer wrote in to say...

    Ross: see “Formal Weirdness“.

    • #43
    • Comment
    • Thu 6 Jan 2011
    • 2036
    Ross Olson wrote in to say...

    Eric as you wrote: “The only things I can think of that get outlines are focused form elements, which the reset doesn’t touch; and focused hyperlinks, which I’m trying to avoid touching in the first place”.

    If form elements are to be avoided, a is a special case, and outline only affects those two sets then there’s no reason to reset the outline at all. Hence Option 2.

    • #44
    • Comment
    • Fri 7 Jan 2011
    • 0756
    Philippe wrote in to say...

    As I’ve (vocally) noted in the past, I never liked / used / needed a reset css stylesheet (I set my css, no need for a reset…). That being said, having suffered many times, as a user, from the lack of any focus indication in the past, I’ll vote for option 2, which seems the less damaging one.

    (thanks Eric for updating the stylesheet to tackle that problem)

    • #45
    • Comment
    • Fri 7 Jan 2011
    • 1046
    Scott wrote in to say...

    Yes, I would vote for #2 as well. As others have said, the outline style is intended for focused elements. If a browser decides that one of the other elements should become focusable (say ‘address’) for whatever reason, then you’ve lost your focus style for that element.

    Future-proofing is noble and all, but you can’t protect against every possibility. And the current reset doesn’t do that anyway – what if a browser decides that all paragraphs should have blue text by default?

    • #46
    • Comment
    • Fri 7 Jan 2011
    • 1550
    Bridget Stewart wrote in to say...


    While I believe you have an excellent point about how differently each browser handles focus styles, I still don’t find any of those differences to be “disruptive” as was/is the case with the differences in padding, margins and other bits that vendors used in their default styles.

    In the case where focus styles have not been updated to align with other design elements, the default handling has a familiar feel to it for the user of that particular browser. In fact, it has been that issue that has me considering whether it is beneficial to alter the default focus styles at all. But, I believe that is a discussion unto itself, not best served here. Not to mention, I can also argue what’s good about changing those styles to align with the design. So, pardon my split decision on that one.

    Regardless, none of those varied styles for focus have a strong negative impact on layout, which I believe has been the greatest strength of the reset stylesheet.

    Just my opinion, of course.

    • #47
    • Comment
    • Sat 8 Jan 2011
    • 1153
    Isaac Lin wrote in to say...

    After reading the discussion in the comments, I agree with option 2. The weirdness with forms and :focus comes from different interactive UI design from the browsers. The section on the outline property in the CSS specification is within the UI chapter and is titled “Dynamic outlines”, and the associated discussion indicates that the motivation was interactive UI elements. I think this is an area where latitude to support innovation from the browser implementers is desirable.

    • #48
    • Comment
    • Mon 10 Jan 2011
    • 0512
    Wolfgang Löer wrote in to say...

    I also favor Option 2 (note that I liked it way before it became popular in the comments! ;)).

    – Outlines on other elements apparently are no problem right now. If they do appear, it may be better anyway to leave them alone by default, much like with links right now.
    – Option 2 also, in contrast to the other options, simplifies the stylesheet a bit, which is always a good thing.

    • #49
    • Comment
    • Thu 13 Jan 2011
    • 0509
    graham wrote in to say...

    I’d say option 3 but adding the predefined :focus styles at the bottom of the reset with a comment similar to the previous remember to define focus styles stating to change the styles or move the style to the main/generic style sheet.

    This keeps at least a basic outline on links for when people forgot to add them in, as was the case when building sites with your previous reset.

    It’s a fuzzy line between resetting everything to a consistent cross browser level and giving developers the nudge they need to make sure they don’t miss important styles out.

    • #50
    • Pingback
    • Mon 17 Jan 2011
    • 0454
    Received from The CSS reset has been reset « Gabriel de Kadt

    […] of all CSS resets hits version 2.o beta: Eric Meyer’s Reset Revisited. See also the subsequent thoughts on how to handle […]

    • #51
    • Pingback
    • Mon 23 Sep 2013
    • 1454
    Received from So, I Was Building This Site With Zurb Foundation, When This Happened... | Adam Wills

    […] Eric Meyer: Looking for Focus […]

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

January 2011
December February