Looking For Focus

Comments (51)

1. 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. 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. I would say 3rd as well. I often forget about defining and testing :focus

4. 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. 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. 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. 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. 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. 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. As far as i can tell opt 3 would be the best choice to fix this issue

11. 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. 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 :: Wednesday, January 5th, 2011 11:22am

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

    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. 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. 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. 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. 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. 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. 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. 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. Here’s another vote for #2.

23. 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. The above comment should have read “defaults for focus on forms and anchor elements” — boooooo on my typing skills!

25. 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. 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. “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. 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. 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. I vote for number #2.

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

    AND

    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. 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. 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. Option 2 – Forward compatibility will always be a problem, as seen with the elements introduced in HTML 5.

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

    (see https://developer.mozilla.org/en/CSS/%3ainvalid)

36. 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. 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. 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. It’s a bit more [B] than [A], Ross, though neither is fully realizable given the tools at our disposal.

40. 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. If it is more [B] then why aren’t form elements dealt with?

42. Ross: see “Formal Weirdness“.

43. 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. 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. 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. William,

    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. 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. 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. 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 :: Monday, January 17th, 2011 4:54am

    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 :: Monday, September 23rd, 2013 2:54pm

    So, I Was Building This Site With Zurb Foundation, When This Happened... | Adam Wills

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

Add Your Thoughts

• Trackback URL
• Comments RSS feed'

Name

E-mail (required but not displayed)

URI (optional)

Meyerweb dot com reserves the right to edit or remove any comment, especially when abusive or irrelevant to the topic at hand.

HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <em> <i> <q cite=""> <s> <strong> <pre class=""> <kbd>

---

Your Comment (Markdown supported)

if you’re satisfied with it.

Comment Preview

Δ