Normalize.css: 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.

[thierryk]

I like #649 but I think it is important to offer a plan B for people who've been relying on Normalize for some of these styles.

What are the options out there?
I know about Sanitize but I don't like some of its opinionated styles (i.e. its rules for [hidden] go "too far").

I'd like to see a project that includes elements that are supposed to include opinionated styles (i.e. margin for body) but with non-opinionated values.
In other words, we know that generic styles should/must be set but we should only offer "suggested values" - values that authors may change as they wish (rather than having to overwrite them).

Does that make sense?

[jonathantneal]

@thierryk, feel free to open an issue with sanitize.css to remove the “too far” opinionated hidden rules (i presume you mean these, which at one point followed a completely reasonable postulation of the spec), and I will be very willing to accommodate changes and push a timed new year release.

sanitize has no desire to get involved in form styling, so that leaves room for yet another opinionated layer. And then of course there’s bootstrap, react boilerplate, html5 boilerplate, etc.

[battaglr]

It's a bit complicated to have a focused discussion about #649 because it changes many things at once —I think it would be nice to discuss some of these separately.

When I said:

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

It was just in reference to the rule of the current issue:

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

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

[thierryk]

@jonathantneal Sanitize is a project about opinionated styles, so even though I don't like that rule, it does not mean it does not belong in there. It is just a choice I do not agree with.

What I'm talking about in term of a "companion project" is something that'd group styles related to generic elements—styles that we'd expect authors to include in their project no matter what (i.e. margin on body). The opinionated part I'm talking about is not related to the values that would be chosen (as I said previously authors would be free to use their own) but rather to the elements and styles that would be involved.
For example, form controls are tricky to style, so it may be beneficial for users to know what and how elements should be styled (i.e. font on input) to get proper results across the board. In my opinion, we're in need for a library that helps people to style things in a "smart" way, rather than styling things for them. I'm thinking about a styles sheet designed to address the many gotchas rather than one that delivers a particular look and feel (i.e. Bootstrap).

@battaglr Too late! ;-)

[jonathantneal]

@thierryk, that sounds like a very good idea.

@battaglr, I followed, and the bigger discussion can happen at #649

[ianmcburnie]

The 100% font-size on form controls is another difficult (impossible?) one to unset. I don't see an explanation of why this rule is there, but it seems to allow font-size to cascade into the control from it's parent, which is non-default browser behaviour (I haven't done a tonne of research on this, just a few quick tests, so please correct me if I'm wrong!).

/**
 * 1. Change the font styles in all browsers (opinionated).
 * 2. Remove the margin in Firefox and Safari.
 */

button,
input,
optgroup,
select,
textarea {
  font-family: sans-serif; /* 1 */
  font-size: 100%; /* 1 */
  line-height: 1.15; /* 1 */
  margin: 0; /* 2 */
}

How would I get back to the browser default font-size and behaviour if I wanted to?

How about an opinionize.css? ;-)

[jonathantneal]

Due to lack of movement, I will consider this resolving by https://github.com/necolas/normalize.css/pull/649

[jonathantneal]

Resolved by #649