How to unset opinionated outline-width rule?

[ianmcburnie]

Is there a way to unset this opinionated rule back to each browser's default value:

/**
 * Remove the outline on focused links when they are also active or hovered
 * in all browsers (opinionated).
 */

a:active,
a:hover {
  outline-width: 0;
}

So far I haven't found a way (there is no 'auto'). If this is the case, please can we remove it?

[garrettw]

CSS does support values of initial and unset -- have you tried either of those to see if they do what you're wanting?

[ianmcburnie]

Thanks Garrett.

I had tried the value of initial, but it does not work. Apply it in Firefox, then hover over a link that has focus, to see what I mean.

---

Expected:

---

Actual (with unset, inherit, or initial):

---

I hadn't tried the unset value, I'd forgotten about that one to be honest (maybe because it's fairly recent and perhaps not fully supported yet), but it seems all that does is use a combination of inherit and initial.

[ianmcburnie]

I'd also like to know the reasoning and justification behind this rule. Why prevent remove the browser's default keyboard focus indicator on mouse hover? It seems unnecessary and could have unintended consequences for users of assistive technology.

[thierryk]

Why prevent the browser's default keyboard focus indicator on mouse hover?

In my opinion, this is because the focus ring is not that important in the presence of a pointing device. I doubt this styling would create accessibility issues.

[ianmcburnie]

I should have said 'remove' rather than 'prevent'. I agree that it probably shouldn't cause any serious accessibility issue. But I just wonder why go to the bother of removing a focus indicator that is already there? It looks a bit strange to me when it appears and disappears on mouse over and mouse out.

It can actually cause a bit of confusion on links with a large hit area (such as a big square, item tile), because if the mouse cursor happens to be resting over one of these tiles, then no keyboard focus indicator shows up when using TAB key to move focus to the link. I've seen bugs filed by QA for this exact scenario, thinking the link has no focus indicator, when in fact it's a simple misunderstanding caused by this rule (a good example of an unintended consequence).

Anyway, I would definitely like to get a bit of an alternative perspective as to why the rule is there.

[garrettw]

Personally, I disagree with that rule as well as ones like it. I made my own CSS normalize/reset called Vitals which does things a bit differently - you might check it out and see if you like it. :)

[thierryk]

Anyway, I would definitely like to get a bit of an alternative perspective as to why the rule is there.

I'm pretty confident it is there because most designers complain about "focus rings". It is a way to hide the focus indicator from pointing-device users while preserving those focus rings for keyboard users.

I've seen bugs filed by QA

I've seen that too but it mostly relates to the fact that QA often does not test for A11Y in respect of context (i.e. keyboard only).

[ianmcburnie]

Ohhh, I see. Thanks Thierry. I definitely know the complaint you are talking about. I also hear this opinion from designers a lot and had forgotten about this pure css 'solution' for it. Sorry for being a bit slow on the uptake! I was only coming at this from the perspective of a user who switches between keyboard, mouse and touch. For me that is also a valid testing context (had to do this back in my Win8 days), but it goes without saying that keyboard-only is another context (and a higher priority one IMHO).

Having said that, I still don't like the rule, I prefer having the more 'tactile' sense that the outline provides (in some browsers) on mouse down, it let's me know my click was registered and the linked page is on it's way. Anyway, I do appreciate that not all browsers have this behaviour, so I guess the justification is that Normalize.css wanted to normalize it one way or another :-)

Personally though I think it might be better left alone, because without a way to unset the rule, I can't upgrade (I use less-plugin-npm-import to import the less file directly from node_modules folder, so it's not like I can just make the edit in a local normalize.css file).

Anyway, I appreciate the discussion on this! Cheers!

Garret, I will definitely check out your project, thanks.

[garrettw]

@thierryk How does this rule preserve the focus ring for keyboard users at all?

[garrettw]

@ianmcburnie Fair warning - I just created Vitals not long ago so it's pretty light on documentation at this point. And as you can probably tell, I haven't even made a version tag yet.
So if you do try it out, please let me know how it works for you! I need the feedback.

[thierryk]

How does this rule preserve the focus ring for keyboard users at all?

By relying on pseudo-classes that don't have much to do with keyboard navigation.

Having said that, I still don't like the rule...

For what it is worth I don't like that rule either—for at least 3 reasons:

1. it prevents authors from resetting this (opinionated) styling
2. it creates a UX issue in a multi-context environment (pointing-device + keyboard navigation)
3. it is not a "normalization" per se.

In my opinion, # 1 is a big deal. May be we should investigate the following approach to see if it could be a better choice:

a:active,
a:hover {
  outline-color: transparent;
}

That way, users should be able to unset this styling via:

a:active,
a:hover {
  outline-color: initial;
  outline-color: -webkit-focus-ring-color;
}

The above seems to work just fine, but I didn't check in anything other than Chrome and Firefox on Mac. Could someone check across browsers and report here?

@jonathantneal @battaglr could you guys take a look at this?

[jonathantneal]

@thierryk, I do like that. I’ll create some tests.

I will continually disapprove of these convenience styles, and if there’s ever consensus to remove any of them, I shall, gladly. :)

[thierryk]

@jonathantneal fwiw, I think Normalize should do nothing more than normalizing styles across browsers. Authors should know what to expect from it. In other words, any change should be predictable.

[battaglr]

Let's get rid of this opinionated and convenience styles. 😉

[jonathantneal]

@thierryk, @battaglr, please review #649. This would resolve this issue and allow me to close future issues related to convenience styles.