- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 Feb 2023 17:57:03 +0000
- To: public-css-archive@w3.org
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'` <details><summary>The full IRC log of that discussion</summary> <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`.<br> <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.<br> <fantasai> +1<br> <florian> q+<br> <dbaron> emilio: If we go with `outline-color` I'd at least like `outline: auto` to not expand to `outline-color: currentColor`<br> <astearns> ack florian<br> <masonf> q+<br> <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<br> <astearns> ack masonf<br> <dbaron> ... be accent-color, but whether and how you do that is platform-dependent.<br> <dbaron> masonf: Clarify: is proposal to change initial value for outline-color to accent-color, or ???<br> <smfr> q+<br> <dbaron> emilio: Allow the accent-color computed value to change the rendering of the auto-style outline... no default value changes involved.<br> <chris> this seems untestable, so it is *allowing* things but not constraining them<br> <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.<br> <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.<br> <emilio> q+<br> <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.<br> <fantasai> Yeah, if the focus outline isn't a shade of gray, it's generally the accent color<br> <chris> q+<br> <dbaron> masonf: As an author you can achieve that withoutline-color: accent-color, no?<br> <astearns> ack smfr<br> <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.<br> <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.<br> <dbaron> emilio: Would you be similarly concerned about using outline-color?<br> <dbaron> smfr: yes<br> <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.<br> <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?<br> <dbaron> emilio: Gecko falls back to system accent color.<br> <dbaron> smfr: sounds better than falling back to outline-color.<br> <dbaron> emilio: ... Accent-color is a hint so you're allowed to ignore it.<br> <emeyer> q+<br> <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.<br> <astearns> ack emilio<br> <astearns> ack chris<br> <emilio> q+<br> <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?<br> <astearns> ack emeyer<br> <florian> q+<br> <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?<br> <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.<br> <astearns> ack emilio<br> <chris> q+ to mention system colors<br> <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.<br> <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.<br> <astearns> ack florian<br> <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.<br> <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.<br> <astearns> ack chris<br> <Zakim> chris, you wanted to mention system colors<br> <dbaron> florian: User sheet that says "my focus ring really needs to be X because otherwise it's an a11y problem"... ?<br> <emilio> q<br> <emilio> q+<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to discuss the compat implications of changing initial value of outline-color<br> <chris> https://w3c.github.io/csswg-drafts/css-color-4/#css-system-colors<br> <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.<br> <PaulG> q+<br> <chris> while currentColor is a text color<br> <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.<br> <masonf> +1 to that proposal. That gives the default behavior Emilio wants, but the author/user control over the outline.<br> <florian> [fantasai's suggestion would deal with the concern I expressed]<br> <astearns> ack emilio<br> <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.<br> <dbaron> emilio: not opposed to fantasai's proposal...<br> <masonf> q+<br> <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.<br> <astearns> ack PaulG<br> <chris> ah we are back to the stripes function<br> <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?<br> <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.<br> <dbaron> masonf: I don't think accent-color is the mechanism through which high contrast is influenced.<br> <emilio> s/???/accent-color: <something-not-a-system-color>/<br> <masonf> q?<br> <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.<br> <astearns> ack masonf<br> <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.<br> <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.<br> <dbaron> florian: You can't guarantee that it's a single color -- could be 2 lines, gradient, etc.<br> <dbaron> masonf: Remains the case with fantasai's proposal -- with outline-style: auto can still do those things.<br> <dbaron> emilio: Seems weird to use outline-style: non-auto (?) and allow color to ???<br> <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.<br> <dbaron> emilio: Can get that too with accent-color.<br> <dbaron> masonf: But then they're not separate, could change color as moving around page to controls with different accent color.<br> <dbaron> emilio: ?<br> <dbaron> masonf: outline-color seems more explicit<br> <dbaron> emilio: If the outline applies to form controls then they're not so independent anymore.<br> <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.<br> <florian> +1 again to fantasai<br> <dbaron> masonf, emilio: that's fair<br> <masonf> +1<br> <masonf> +1 to auto<br> <dbaron> fantasai: should new initial value keyword for outline-color be auto, normal, or something else?<br> <masonf> +1 to automagic<br> <dbaron> florian: auto... it doesn't seem normal.<br> <bramus> +1 auto<br> <tantek> +1 auto<br> <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'<br> <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.<br> <dbaron> florian: oh, current initial value of outline-color is invert...<br> <dbaron> ?: Does anyone implement that?<br> <dbaron> ?: no, but Opera 11 did.<br> <bradk> auto seems right<br> <dbaron> ?: ?<br> <dbaron> fantasai: I think we should exlpicitly change the initial value.<br> <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'<br> <emilio> q+<br> <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<br> <astearns> ack emilio<br> <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.<br> <dbaron> emilio: We can probably wait to resolve on this.<br> <emilio> s/like currentColor/like caret-color<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7761#issuecomment-1440512109 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 22 February 2023 17:57:06 UTC