[css-ui] Tweaking outline-style: auto colors.

[emilio]

https://bugzilla.mozilla.org/show_bug.cgi?id=1791051 shows an interesting interop difference: https://jsfiddle.net/ht85jacp/

• Firefox allows customizing auto-style outline using accent-color.
• Chrome allows that using outline-color.
• WebKit doesn't allow that.

I can provide some reasoning to why I implemented the Firefox behavior. outline-style: auto is intended to be the OS accent color by default. It behaves more like appearance: auto form control borders, so using outline-color would be rather weird. On the flip side, using border-color on form controls disables native appearance altogether, so maybe it's not that weird.

I have a preference for Gecko's behavior, but I'd be happy to listen to reasoning from Chrome's folks about why they honor outline-color instead... I think part of the issue I don't love it is because outline: auto would set outline-color: currentColor, which seems pretty unfortunate.

[argyleink]

I'd be happy to listen to reasoning from Chrome's folks about why they honor outline-color instead

i can try and uncover why this was done the way it was, see if there was strong reasoning or an accident

[mfreed7]

So accent-color is meant for form controls ("widgets"), and I don't really think it should be used to change the focus ring or outline color on all elements. It is very unfortunate that the spec for accent-color was basically written as "do what you like, UA", so this is a grey area. But that was my interpretation of the spirit of the feature. Accent colors are pieces of form controls that typically render as an "accent" to the control. I don't think the outline falls into this category.

I'm curious about your comment that outline-style: auto is intended to be the accent color - isn't outline-style just the style (dotted, solid, etc.) of the outline?

I'm probably missing your point, so help me. But in Chromium, setting outline-color by itself just changes the color of whatever outline would normally be drawn. So setting button {outline-color:red} is a common way to change the color of focus rings without changing their style or dealing with :focus-visible rules. Setting outline-style:auto disables the focus ring painting behavior and just turns on the default outline (black 1.5px solid). But this feels fairly easy and works well, I'm not sure why we'd want to push toward accent-color for outlines.

[emilio]

I'm curious about your comment that outline-style: auto is intended to be the accent color - isn't outline-style just the style (dotted, solid, etc.) of the outline?

outline-style: auto, when originally implemented, was the OS-native outline. In fact the spec still has:

The auto value permits the user agent to render a custom outline style, typically a style which is either a user interface default for the platform, or perhaps a style that is richer than can be described in detail in CSS, e.g. a rounded edge outline with semi-translucent outer pixels that appears to glow.

So when implementing accent-color, I made outline-style: auto follow it so that the outline color of widgets was consistent.

Setting outline-style:auto disables the focus ring painting behavior and just turns on the default outline (black 1.5px solid). But this feels fairly easy and works well, I'm not sure why we'd want to push toward accent-color for outlines.

Well, in Gecko outline-style: auto is not just an alias for black 1.5px solid. For us, it has two segments (one of 2px, one of 1px) of different colors (accent color + accent-foreground color).

The default UA sheet in the HTML spec has:

:focus-visible { outline: auto; }

That really expands to outline-style: auto; outline-color: currentColor; .... I don't think outline: auto should force black (or lose colors) of the default outline.

[mfreed7]

So I think I agree with you that setting outline: auto should "go back to native appearance" and not just set an outline that's different than the default. That behavior does feel kind of broken.

But I think that in a similar way, outline-color should just change the color of that default appearance, without changing anything else. And that should be the "knob" used to change color of focus rings, instead of accent-color. The accent-color property is meant to target things that don't already have a property, like widgets within form controls. Since there's already a property that is exactly specific to the outline color (outline-color), let's use it.

[emilio]

But I think that in a similar way, outline-color should just change the color of that default appearance, without changing anything else. And that should be the "knob" used to change color of focus rings, instead of accent-color. The accent-color property is meant to target things that don't already have a property, like widgets within form controls. Since there's already a property that is exactly specific to the outline color (outline-color), let's use it.

Well, for natively-themed form controls, the accent-color should probably also control the outline color shouldn't it? The same way it might affect the border colors and so on.

The way to make outline: auto do the right thing while respecting outline-color, would be to change the initial value of outline-color, is that what you're proposing?

[mfreed7]

Well, for natively-themed form controls, the accent-color should probably also control the outline color shouldn't it? The same way it might affect the border colors and so on.

I don't know! I think here, too, the user assumes the focus ring is something the page provides, and isn't specific to the element. I feel like it'd be weird for a normally-blue focus ring to change to pink when it hit a pink-accented checkbox, for example.

The way to make outline: auto do the right thing while respecting outline-color, would be to change the initial value of outline-color, is that what you're proposing?

So first, I meant (initially) and I think you meant here, outline-style: auto, not outline:auto, right? Since outline is a shorthand, I'm not sure we should add an auto value to that, but maybe.

For outline-style, the spec seems pretty clear what auto itself means, as you pointed out. However, it says this about the other two:

As such, this specification does not define how the outline-color and outline-width are incorporated or used (if at all) when rendering auto style outlines.

Perhaps we should amend that to say something about trying to use outline-color as much as possible when outline-style: auto? It probably can't be more specific or normative than that, since the UA style (e.g. Firefox's) might include more than one color, or gradients, etc. But I'm in favor of trying to push in that direction.

[emilio]

So first, I meant (initially) and I think you meant here, outline-style: auto, not outline:auto, right? Since outline is a shorthand, I'm not sure we should add an auto value to that, but maybe.

No, I meant outline: auto. outline: auto expands to outline-style: auto; outline-color: currentColor; outline-width: medium;. Since currentColor can't be magic, we'd need a different initial outline-color of sorts.

Perhaps we should amend that to say something about trying to use outline-color as much as possible when outline-style: auto? It probably can't be more specific or normative than that, since the UA style (e.g. Firefox's) might include more than one color, or gradients, etc. But I'm in favor of trying to push in that direction.

I think we at least need a fix for outline: auto to do the right thing rather than forcing black outlines. I think in Blink what you have in the UA sheet is something like -webkit-focus-ring-color, which doesn't follow the spec afaict and causes that unintended behavior.

[mfreed7]

So first, I meant (initially) and I think you meant here, outline-style: auto, not outline:auto, right? Since outline is a shorthand, I'm not sure we should add an auto value to that, but maybe.

No, I meant outline: auto. outline: auto expands to outline-style: auto; outline-color: currentColor; outline-width: medium;. Since currentColor can't be magic, we'd need a different initial outline-color of sorts.

Sorry - can you help me with a spec link to the definition for outline: auto? I don't see it here, it just appears to be a normal shorthand for [ <'outline-color'> \|\| <'outline-style'> \|\| <'outline-width'> ], and then those have their own initial values, which are outline-style: none; outline-color: invert; outline-width: medium;.

If that's the wrong spec link, help me find the right one, please?

+@lilles for more informed comments here.

[lilles]

@mfreed7 outline: auto would set outline-style: auto because that's the only longhand that accepts the auto keyword. The other longhands will be reset to their initial values since there are no values for them in the shorthand. That is, outline-color: currentColor and outline-width: medium.

[mfreed7]

@mfreed7 outline: auto would set outline-style: auto because that's the only longhand that accepts the auto keyword. The other longhands will be reset to their initial values since there are no values for them in the shorthand. That is, outline-color: currentColor and outline-width: medium.

Ahh. Thanks!

Ok, I see the problem now. Would a fix be to change the :focus-visible UA style to outline-style:auto instead of outline:auto then?

[css-meeting-bot]

The CSS Working Group just discussed [css-ui] Tweaking outline-style: auto colors., and agreed to the following:

• RESOLVED: outline-style: auto outlines, if influenced by an author color, are influenced by outline-color, which itself gets a new initial value keyword 'auto' which computes to 'currentColor' when outline-style is not auto and otherwise represents the 'accent-color'

The full IRC log of that discussion

<dbaron> emilio: This about whether `outline-style: auto` respects or not `outline-color` and/or `accent-color`. Behavior is all over the place. WebKit allows neither. Blink uses `outline-color`, Gecko uses `accent-color`.
<dbaron> emilio: Reason I think Gecko behavior is preferable is 2 reasons: `outline: auto` using the `outline` shorthand resets `outline-color` to `currentColor`, which seems wrong at least 99% of the time. and (2) it's more consistent with how form controls work, so using accent-color makes more sense to me.
<fantasai> +1
<florian> q+
<dbaron> emilio: If we go with `outline-color` I'd at least like `outline: auto` to not expand to `outline-color: currentColor`
<astearns> ack florian
<masonf> q+
<dbaron> florian: I think I agree -- some arguments seem st ronger than other,but agree in net. `auto` outline could look like lots of things -- on some platforms it may f ollow the accent and on some platforms it may not. So if it respects any color it should probably be accent-color, but on some platforms it may not respect anything and just stick to one specific thing. So I think say "if you're going to be influenced by any property, it should
<astearns> ack masonf
<dbaron> ... be accent-color, but whether and how you do that is platform-dependent.
<dbaron> masonf: Clarify: is proposal to change initial value for outline-color to accent-color, or ???
<smfr> q+
<dbaron> emilio: Allow the accent-color computed value to change the rendering of the auto-style outline... no default value changes involved.
<chris> this seems untestable, so it is *allowing* things but not constraining them
<dbaron> masonf: My initial reaction was that accent-color was for form controls, and now this applies toeverething on the page. IT doesn't feel like an accent to me.
<dbaron> masonf: I'm wondering if there's another way to fix the problem, but I don't have a well thought out solution. But one thing I put on the issue was wondering if we could change `:focus-visibile` UA styles to only be `outline-style: auto` so it doesn't reset the color.
<emilio> q+
<dbaron> florian: `outline` is sometimes used for decorative purposes but usually for focus indicator... and focus indicator usually matches form controls. On Mac OS changing system accent color changes focus indicator, so going after accent color makes sense.
<fantasai> Yeah, if the focus outline isn't a shade of gray, it's generally the accent color
<chris> q+
<dbaron> masonf: As an author you can achieve that withoutline-color: accent-color, no?
<astearns> ack smfr
<dbaron> florian: you could, but as specified (and I Think implemented), setting outline: auto sets outline-color to currentColor, so if that starts influencing the color that's odd.
<dbaron> smfr: I think I agree with masonf... like to hear from web designers, maybe jensimmons... should outlines be controlled by accent-color. accent-color is author controlled but system highlight color is user controlled. So concerned about using accent color.
<dbaron> emilio: Would you be similarly concerned about using outline-color?
<dbaron> smfr: yes
<dbaron> florian: That's what I was saying about specifying: saying that if you're influenced by *any* color it should be accent color, but you don't have to be.
<dbaron> smfr: I think I'd choose accent color in that case, but want some more feedback about whether that's the right thing. If accent-color not specified, fall back to outline-color?
<dbaron> emilio: Gecko falls back to system accent color.
<dbaron> smfr: sounds better than falling back to outline-color.
<dbaron> emilio: ... Accent-color is a hint so you're allowed to ignore it.
<emeyer> q+
<dbaron> emilio: I think allowing customizing outline appearance is nice, auto outline has a11y benefits. But if WebKit wants to do something different... accent-color seems like the right property to allow you to choose.
<astearns> ack emilio
<astearns> ack chris
<emilio> q+
<dbaron> chris: I agree with smfr that the crux is author control versus user control. This seems to be adding an allowed behavior to a list of unspecified behaviors, so it seems to be making what people already do spec compliant. Not clear if it's allowed, or if it's advice. Are we suggesting, or is it do whatever you want, but did you forget about this one?
<astearns> ack emeyer
<florian> q+
<dbaron> emeyer: Thinking of this as an author, it's a little weird to me that setting outline-style: auto would fall back to a color from a property that doesn't have the word outline in it. But the behavior probably actually makes more sense. I wonder if instead of defaulting to currentColor it makes sense for outline to default to whatever the system keyword is. But that might require too much change in browsers?
<dbaron> ... I set my outline to be auto, but the color is not my outline-color. Unless you know it comes from accent-color, might be difficult to work out why. But maybe it's the preferred behavior so not too many authors will run into it as a problem. But if default value of outline-color could be the system color that seems preferable to me, but don't know if it's reasonable.
<astearns> ack emilio
<chris> q+ to mention system colors
<dbaron> emilio: Changing the default of outline-color seems not feasible. Changing the expansion of `outline: auto` seems potentially feasible, but that would still make `outline-style: auto` do something relatively weird.
<dbaron> emilio: I think not honoring `outline-color` is slightly better... but then we can get into user versus author choice question that chris and smfr raised.
<astearns> ack florian
<dbaron> florian: I was initially supporting emilio's proposal, but I'm wondering now because of user vs. author thing, yes, the UA can disregard that and display the system colors... could have a setting. But if we think about user style sheets, if we influence the style of the outline with the outline-color property, a user could have a !important outline-color... but they're ok with accent-color... then there's no easy override for user sheets.
<dbaron> emilio: The focus ring on form controls when natively styled do follow accent color, so that would create an odd behavior in my opinion.
<astearns> ack chris
<Zakim> chris, you wanted to mention system colors
<dbaron> florian: User sheet that says "my focus ring really needs to be X because otherwise it's an a11y problem"... ?
<emilio> q
<emilio> q+
<astearns> ack fantasai
<Zakim> fantasai, you wanted to discuss the compat implications of changing initial value of outline-color
<chris> https://w3c.github.io/csswg-drafts/css-color-4/#css-system-colors
<dbaron> chris: In color 4, higlight and accent color are both described as backgrounds. If we agree on this, I can change the description there. We don't have anything in the non-deprecated system colors which is an outline color.
<PaulG> q+
<chris> while currentColor is a text color
<dbaron> fantasai: I was going to go back to emeyer's comment about changing initial value of outline-color... I don't think we can change it, because when outline-style is not auto we can't change it, but we could change the initial value of outline-color to be some kind of auto value that computes to currentColor if outline-style is not auto and computes to accent-color if outline-style is auto.
<masonf> +1 to that proposal. That gives the default behavior Emilio wants, but the author/user control over the outline.
<florian> [fantasai's suggestion would deal with the concern I expressed]
<astearns> ack emilio
<dbaron> fantasai: Multi-level fallback... look at outline-color, then if it's the initial value the UA will look at accent color. But if you set outline-color to something else specific you'd get that. It's a possible solution, not sure if good. It works around compat stuff and allows both outline-color and accent color to influence.
<dbaron> emilio: not opposed to fantasai's proposal...
<masonf> q+
<dbaron> emilio: I was going to mention about chris's background versus foreground color -- at least some browsers (Blink and Gecko) do paint 2 outlines when you do outline-style: auto so you are guaranteed to show some outline even if it matches the background.
<astearns> ack PaulG
<chris> ah we are back to the stripes function
<dbaron> PaulG: Does anyone know ... I was under the impression that accent-color had something to do with high contrast mode. Would then specifying outline-color be a problem because then high contrast mode it would not change?
<dbaron> emilio: There are in the sense that if you specify a non-auto outline-color that isn't the system color it would not change... but I think that's the expected behavior. Similarly if you specify ???. Unless you specify forced-color-adjust: none.
<dbaron> masonf: I don't think accent-color is the mechanism through which high contrast is influenced.
<emilio> s/???/accent-color: <something-not-a-system-color>/
<masonf> q?
<dbaron> PaulG: comfort level for a11y reasons: if someone makes a codepen or something to demonstrate how it would work, should be tested in high contrast mode, to see which settings a user might use, and to preserve choice.
<astearns> ack masonf
<dbaron> masonf: I just wanted to say I also like fantasai's proposal. Wanted to address 1 question emilio raised: I think under that proposal if you had outline-style: auto and outline-color: auto, the UA could paint the high-accessibility... 2 rings with white outside and color inside -- I believe we could still do that in that scenario.
<dbaron> emilio: I think that's why accent-color seems like a better fit -- it doesn't override the color completely, but says you should render the outline *using* this color, but not completely using this color. You have outline-style: solid for that.
<dbaron> florian: You can't guarantee that it's a single color -- could be 2 lines, gradient, etc.
<dbaron> masonf: Remains the case with fantasai's proposal -- with outline-style: auto can still do those things.
<dbaron> emilio: Seems weird to use outline-style: non-auto (?) and allow color to ???
<dbaron> masonf: The part I liked was that you could say `outline-style: auto` and provide a color and still get the high-accessibility ring.
<dbaron> emilio: Can get that too with accent-color.
<dbaron> masonf: But then they're not separate, could change color as moving around page to controls with different accent color.
<dbaron> emilio: ?
<dbaron> masonf: outline-color seems more explicit
<dbaron> emilio: If the outline applies to form controls then they're not so independent anymore.
<dbaron> fantasai: Example: say someone made accent color red for invalid controls and green for valid controls, but want focus outline to be consistent color throughout the page. Can't do that with only accent-color and not outline-color. Default to accent-color makes sense, but see benefit to controlling independently.
<florian> +1 again to fantasai
<dbaron> masonf, emilio: that's fair
<masonf> +1
<masonf> +1 to auto
<dbaron> fantasai: should new initial value keyword for outline-color be auto, normal, or something else?
<masonf> +1 to automagic
<dbaron> florian: auto... it doesn't seem normal.
<bramus> +1 auto
<tantek> +1 auto
<fantasai> PROPOSED: outline-style: auto outlines, if influenced by an author color, are influenced by outline-color, which itself gets a new initial value keyword 'auto' which computes to 'currentColor' when outline-style is not auto and otherwise represents the 'accent-color'
<dbaron> proposed resolution: add a new auto keyword to outline-color, that means currentColor when outline-style is non-auto and means to use the accent-color when outline-style is auto.
<dbaron> florian: oh, current initial value of outline-color is invert...
<dbaron> ?: Does anyone implement that?
<dbaron> ?: no, but Opera 11 did.
<bradk> auto seems right
<dbaron> ?: ?
<dbaron> fantasai: I think we should exlpicitly change the initial value.
<dbaron> RESOLVED: outline-style: auto outlines, if influenced by an author color, are influenced by outline-color, which itself gets a new initial value keyword 'auto' which computes to 'currentColor' when outline-style is not auto and otherwise represents the 'accent-color'
<emilio> q+
<dbaron> astearns: I think it would be very useful to have a couple of examples of how one might use the different properties for different purposes and why we have the fallback the way we do
<astearns> ack emilio
<dbaron> emilio: There's the question of what the new initial value should compute or resolve to... I think it should compute to auto like currentColor... but maybe it should resolve to the accent-color keyword? That can be a followup question, as long as well-specified. Maybe we can resolve to auto but not sure we can get away with that -- pages might expect rgba() values back.
<dbaron> emilio: We can probably wait to resolve on this.
<emilio> s/like currentColor/like caret-color