Intent to Ship: accent-color CSS property

[Joey Arhar]

Contact emails

jar...@chromium.org

Explainer

https://drafts.csswg.org/css-ui-4/#widget-accent

Specification

https://drafts.csswg.org/css-ui-4/#widget-accent

API spec

Yes

Summary

The accent-color CSS property allows the page to specify a color used by form controls instead of using the builtin default color. For example, "accent-color: red" on an <input type=checkbox> would change the blue color around the checkmark to red.

Blink component

Blink>CSS

TAG review

None, this has already been approved by the CSSWG

TAG review status

Not applicable

Risks

Interoperability and Compatibility

If this is not implemented by other browsers, then form controls will still work the same, they just won't have the custom accent-color.

Gecko: In development (https://bugzilla.mozilla.org/show_bug.cgi?id=1705605)

WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2021-June/031885.html)

Web developers: Positive https://twitter.com/argyleink/status/1360022120810483715 https://bugs.chromium.org/p/chromium/issues/detail?id=1092093 has 26 stars https://bugs.chromium.org/p/chromium/issues/detail?id=1091531 has 17 stars complaining about the new forced blue color which this feature addresses

Is this feature fully tested by web-platform-tests?

Yes

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1092093

Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1193835

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4752739957473280

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/q9zf-frdewo/m/zxw2HuzGAQAJ

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

On Wed, Jun 9, 2021 at 3:57 AM Joey Arhar <jar...@chromium.org> wrote:

Contact emails

jar...@chromium.org

Explainer

https://drafts.csswg.org/css-ui-4/#widget-accent

Specification

https://drafts.csswg.org/css-ui-4/#widget-accent

API spec

Yes

Summary

The accent-color CSS property allows the page to specify a color used by form controls instead of using the builtin default color. For example, "accent-color: red" on an <input type=checkbox> would change the blue color around the checkmark to red.

Blink component

Blink>CSS

TAG review

None, this has already been approved by the CSSWG

I'm hesitating here. On the one hand, CSSWG approval doesn't immediately translate to "TAG review is not needed".

At the same time, I agree this doesn't seem like a feature where the TAG can provide a lot of input.

  

TAG review status

Not applicable

Risks

Interoperability and Compatibility

If this is not implemented by other browsers, then form controls will still work the same, they just won't have the custom accent-color.

Gecko: In development (https://bugzilla.mozilla.org/show_bug.cgi?id=1705605)

Do you know of their plans to ship this?

WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2021-June/031885.html)

Web developers: Positive https://twitter.com/argyleink/status/1360022120810483715 https://bugs.chromium.org/p/chromium/issues/detail?id=1092093 has 26 stars https://bugs.chromium.org/p/chromium/issues/detail?id=1091531 has 17 stars complaining about the new forced blue color which this feature addresses

Looks like a strong signal!

 

Is this feature fully tested by web-platform-tests?

Yes

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1092093

Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1193835

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4752739957473280

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/q9zf-frdewo/m/zxw2HuzGAQAJ

This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKRHr0arTSU6sTq_nLGrf4oxw9g-8YCMB38Yk7EeZDKSg%40mail.gmail.com.

[Manuel Rego Casasnovas]

On 09/06/2021 07:24, Yoav Weiss wrote:
> On Wed, Jun 9, 2021 at 3:57 AM Joey Arhar <jar...@chromium.org
> <mailto:jar...@chromium.org>> wrote:
> Is this feature fully tested by web-platform-tests

> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
>
> Yes

Some tests are marked as ".tentative", shouldn't they be renamed?
https://wpt.fyi/results/css/css-ui?label=master&label=experimental&aligned&q=accent-color

1 test case is failing everywhere ("currentcolor") maybe it needs some
change or the implementation needs to be fixed.

Also there are just a few tests, I guess this is something tricky to
test in WPT. Anyway should we check it applies to more elements than
just checkbox?

Cheers,
Rego

[Emilio Cobos Álvarez]

Hi Joey,

https://github.com/w3c/csswg-drafts/issues/6159 is still open, and it'd
be nice to address since one of the proposals involves changing the
syntax of the property to take multiple colors.

If I recall correctly, the way the Chromium implementation of this
property works right now is switching to "dark mode" form controls for
certain accent color values which you consider as not having enough
contrast.

I don't think that's a great way to go around it, as choosing slightly
different colors dramatically changes the appearance of the controls. It
feels also weird that accent-color would "trump" the color-scheme property.

On 6/9/21 03:57, Joey Arhar wrote:
>
> Contact emails
>
> jar...@chromium.org <mailto:jar...@chromium.org>
>
>
> Explainer
>
> https://drafts.csswg.org/css-ui-4/#widget-accent

> <https://drafts.csswg.org/css-ui-4/#widget-accent>
>
>
> Specification
>
> https://drafts.csswg.org/css-ui-4/#widget-accent
> <https://drafts.csswg.org/css-ui-4/#widget-accent>
>
>
> API spec
>
> Yes
>
>
> Summary
>
> The accent-color CSS property allows the page to specify a color used by
> form controls instead of using the builtin default color. For example,
> "accent-color: red" on an <input type=checkbox> would change the blue
> color around the checkmark to red.
>
>
>
> Blink component
>
> Blink>CSS

> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>

>
>
> TAG review
>
> None, this has already been approved by the CSSWG
>
>
> TAG review status
>
> Not applicable
>
>
> Risks
>
>
>
> Interoperability and Compatibility
>
> If this is not implemented by other browsers, then form controls will
> still work the same, they just won't have the custom accent-color.

It is implemented in Firefox Nightly, fwiw.

And sure, this is true as long as Firefox doesn't ship it, but my
understanding is that this section is not only about "what happens if
Chromium ships it right now", but also about how other browsers can have
interoperable implementations of the feature.

As implemented right now in Chromium and Gecko, some websites would have
pretty different form controls depending on which accent color is
chosen, because we have different thresholds in order to consider
something having little contrast, and Chrome auto-switches to dark mode
controls if that happens (while Firefox just chooses a
better-contrasting foreground color).

-- Emilio

>
>
> Gecko: In development
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1705605
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1705605>)
>
> WebKit: No signal
> (https://lists.webkit.org/pipermail/webkit-dev/2021-June/031885.html
> <https://lists.webkit.org/pipermail/webkit-dev/2021-June/031885.html>)

>
> Web developers: Positive
> https://twitter.com/argyleink/status/1360022120810483715

> <https://twitter.com/argyleink/status/1360022120810483715>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1092093

> <https://bugs.chromium.org/p/chromium/issues/detail?id=1092093> has 26
> stars https://bugs.chromium.org/p/chromium/issues/detail?id=1091531
> <https://bugs.chromium.org/p/chromium/issues/detail?id=1091531> has 17
> stars complaining about the new forced blue color which this feature
> addresses
>
>
> Is this feature fully tested by web-platform-tests

> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?

>
> Yes
>
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1092093
> <https://bugs.chromium.org/p/chromium/issues/detail?id=1092093>
>
>
> Launch bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1193835
> <https://bugs.chromium.org/p/chromium/issues/detail?id=1193835>
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/4752739957473280
> <https://chromestatus.com/feature/4752739957473280>
>
>
> Links to previous Intent discussions
>
> Intent to prototype:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/q9zf-frdewo/m/zxw2HuzGAQAJ
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/q9zf-frdewo/m/zxw2HuzGAQAJ>
>
>
> This intent message was generated by Chrome Platform Status

> <https://www.chromestatus.com/>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKRHr0arTSU6sTq_nLGrf4oxw9g-8YCMB38Yk7EeZDKSg%40mail.gmail.com

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKRHr0arTSU6sTq_nLGrf4oxw9g-8YCMB38Yk7EeZDKSg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Joey Arhar]

> Do you know of their plans to ship this?

Emilio, can you speak for this? Or would it be better for me to file a request for firefox's position?

> Some tests are marked as ".tentative", shouldn't they be renamed?

I added accent-color-visited.tentative.html because Anders suggested to do so in my code review: "Since it's not clear whether or not accent-color should be allowed in :visited (and :visited allow-list is not really well specced in the first place) it's probably good etiquette to mark the test as tentative (accent-color-visited.tentative.html)"

Emilio added accent-color-checkbox-checked-001.tentative.html. It looks like it expects checkboxes to appear different, which is relevant to your next question:

> Also there are just a few tests, I guess this is something tricky to

> test in WPT. Anyway should we check it applies to more elements than
> just checkbox?

I have a bunch of pixel tests internal to chromium here. As for which elements it applies to, I think this might vary between browsers and isn't specified by the spec. For example, WebKit already uses the MacOS system preferences accent color setting to color checkboxes and radios, but it does not do the same for <input type=range> and <progress> like I implemented in Chromium. I could easily imagine WebKit implementing this for checkboxes and radios but nothing else, and again, the spec doesn't say... there may have been more discussion about this in spec issues and CSSWG that I missed though.

Emilio's comments about interop make me feel like maybe we should specify which elements it applies to though, even if WebKit doesn't end up implementing all of them...? I'm open to suggestions here.

Also, the reason I chose those four elements to apply accent-color to is because all of the other form controls can already be styled (at least in chromium) with css properties like color and background-color.

> 1 test case is failing everywhere ("currentcolor") maybe it needs some

> change or the implementation needs to be fixed.

I discussed this with Anders here. I was not aware that it would fail in all browsers, and I'm not sure what to do about it.

> https://github.com/w3c/csswg-drafts/issues/6159 is still open, and it'd

> be nice to address since one of the proposals involves changing the
> syntax of the property to take multiple colors.
> 
> If I recall correctly, the way the Chromium implementation of this
> property works right now is switching to "dark mode" form controls for
> certain accent color values which you consider as not having enough
> contrast.
> 
> I don't think that's a great way to go around it, as choosing slightly
> different colors dramatically changes the appearance of the controls. It
> feels also weird that accent-color would "trump" the color-scheme property.

> And sure, this is true as long as Firefox doesn't ship it, but my
> understanding is that this section is not only about "what happens if
> Chromium ships it right now", but also about how other browsers can have
> interoperable implementations of the feature.
> 
> As implemented right now in Chromium and Gecko, some websites would have
> pretty different form controls depending on which accent color is
> chosen, because we have different thresholds in order to consider
> something having little contrast, and Chrome auto-switches to dark mode
> controls if that happens (while Firefox just chooses a
> better-contrasting foreground color).

I agree with your points, it would be best to address this issue before shipping accent-color. I'll post some updates in the github issue so we can try to converge on the same behavior.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aabe9f68-6df3-01ab-e5d2-372ef19e4492%40mozilla.com.

[Mason Freed]

Just adding a few comments here, since I was involved in the original spec discussions for this feature:

On Wednesday, June 9, 2021 at 12:35:23 PM UTC-7 Joey Arhar wrote:

> Also there are just a few tests, I guess this is something tricky to

> test in WPT. Anyway should we check it applies to more elements than
> just checkbox?

I have a bunch of pixel tests internal to chromium here. As for which elements it applies to, I think this might vary between browsers and isn't specified by the spec. For example, WebKit already uses the MacOS system preferences accent color setting to color checkboxes and radios, but it does not do the same for <input type=range> and <progress> like I implemented in Chromium. I could easily imagine WebKit implementing this for checkboxes and radios but nothing else, and again, the spec doesn't say... there may have been more discussion about this in spec issues and CSSWG that I missed though.

This was definitely discussed, and there were strong opinions that the spec should be decidedly quiet on where and how to apply the accent-color. Several people represented the view that implementations should be allowed (and encouraged) to innovate on form controls, without constraints from this feature. To that end, there can be no WPT tests for the visual appearance of any form control anyway, but definitely not for accent-color.

 

Emilio's comments about interop make me feel like maybe we should specify which elements it applies to though, even if WebKit doesn't end up implementing all of them...? I'm open to suggestions here.

Again here, my original proposal had non-normative guidance for how to use accent-color on each control, but CSSWG disagreed with that. The (rough) consensus was to leave the application of accent-color up to the implementations. WebKit was a strong proponent of *not* specifying which elements to style, or how to style them.

 

> I don't think that's a great way to go around it, as choosing slightly

> different colors dramatically changes the appearance of the controls. It
> feels also weird that accent-color would "trump" the color-scheme property.

Emilio, can you clarify how Firefox went about implementing the requirement that the "UA must maintain contrast for legibility of the control"? The way this is implemented in Chromium (roughly) guarantees a minimum contrast. We do agree that it is abrupt and not ideal, but we're not sure how else we could implement this. Again, having the author provide two colors would have been so much more straightforward. But given the spec, I think something along the lines of what we've implemented is about as good as it's going to get. Ideas appreciated! If the Firefox algorithm is simple enough, perhaps we can use the same algorithm. And think about specifying it.

One point of clarification: accent-color doesn't "trump" the color-scheme in all cases. It only does so when the current color-scheme and the current accent-color don't provide enough contrast.

 

> As implemented right now in Chromium and Gecko, some websites would have

> pretty different form controls depending on which accent color is
> chosen, because we have different thresholds in order to consider
> something having little contrast, and Chrome auto-switches to dark mode
> controls if that happens (while Firefox just chooses a
> better-contrasting foreground color).

Again here, Chromium and Gecko already have different controls, even before/without accent-color. But if the selected accent-color provides suitable contrast, then Chromium and Gecko will roughly agree on the colors used. It is only when the "contrast mitigation" takes effect that they might differ more significantly.

Thanks,

Mason

 

> an email to blink-dev+unsubscribe@chromium.org
> <mailto:blink-dev+unsubscribe@chromium.org>.

> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKRHr0arTSU6sTq_nLGrf4oxw9g-8YCMB38Yk7EeZDKSg%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKRHr0arTSU6sTq_nLGrf4oxw9g-8YCMB38Yk7EeZDKSg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Emilio Cobos Álvarez]

On 6/9/21 21:35, Joey Arhar wrote:
> > Do you know of their plans to ship this?
>
> Emilio, can you speak for this? Or would it be better for me to file a
> request for firefox's position?

It'd be better to request an official position, but I personally don't
object to ship it if the interop situation is reasonable.

> > Some tests are marked as ".tentative", shouldn't they be renamed?
>
> I added accent-color-visited.tentative.html because Anders suggested to
> do so in my code review

> <https://chromium-review.googlesource.com/c/chromium/src/+/2847031/9#message-77af1e5f94546884f2d7af3440fedfb3a4ff01a2>:

> "Since it's not clear whether or not accent-color should be allowed in
> :visited (and :visited allow-list is not really well specced in the
> first place) it's probably good etiquette to mark the test as tentative
> (accent-color-visited.tentative.html)"
>
> Emilio added accent-color-checkbox-checked-001.tentative.html. It looks
> like it expects checkboxes to appear different, which is relevant to
> your next question:
>
> > Also there are just a few tests, I guess this is something tricky to
> > test in WPT. Anyway should we check it applies to more elements than
> > just checkbox?
>
> I have a bunch of pixel tests internal to chromium here

> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/fast/forms/accent-color/;drc=b7ed0ab024e0ebb4d23cdad80339890417bd48da>.

> As for which elements it applies to, I think this might vary between
> browsers and isn't specified by the spec. For example, WebKit already
> uses the MacOS system preferences accent color setting to color
> checkboxes and radios, but it does not do the same for <input
> type=range> and <progress> like I implemented in Chromium. I could
> easily imagine WebKit implementing this for checkboxes and radios but
> nothing else, and again, the spec doesn't say... there may have been
> more discussion about this in spec issues and CSSWG that I missed though.
>
> Emilio's comments about interop make me feel like maybe we should
> specify which elements it applies to though, even if WebKit doesn't end
> up implementing all of them...? I'm open to suggestions here.
>
> Also, the reason I chose those four elements to apply accent-color to is
> because all of the other form controls can already be styled (at least
> in chromium) with css properties like color and background-color.
>
> > 1 test case is failing everywhere ("currentcolor") maybe it needs some
> > change or the implementation needs to be fixed.
>
> I discussed this with Anders here

> <https://chromium-review.googlesource.com/c/chromium/src/+/2847031/3..9/third_party/blink/web_tests/external/wpt/css/css-ui/accent-color-computed.html#b19>.

> I was not aware that it would fail in all browsers, and I'm not sure
> what to do about it.

Colors have historically always resolved to the actual current color:


https://drafts.csswg.org/cssom/#resolved-value-special-case-property-like-color

We should probably add accent-color to the list, unless there's a strong
reason not to follow ~all other color properties?

>
> > https://github.com/w3c/csswg-drafts/issues/6159

> <https://github.com/w3c/csswg-drafts/issues/6159> is still open, and it'd
> > be nice to address since one of the proposals involves changing the
> > syntax of the property to take multiple colors.
> >
> > If I recall correctly, the way the Chromium implementation of this
> > property works right now is switching to "dark mode" form controls for
> > certain accent color values which you consider as not having enough
> > contrast.
> >
> > I don't think that's a great way to go around it, as choosing slightly
> > different colors dramatically changes the appearance of the controls. It
> > feels also weird that accent-color would "trump" the color-scheme
> property.
>
> > And sure, this is true as long as Firefox doesn't ship it, but my
> > understanding is that this section is not only about "what happens if
> > Chromium ships it right now", but also about how other browsers can have
> > interoperable implementations of the feature.
> >
> > As implemented right now in Chromium and Gecko, some websites would have
> > pretty different form controls depending on which accent color is
> > chosen, because we have different thresholds in order to consider
> > something having little contrast, and Chrome auto-switches to dark mode
> > controls if that happens (while Firefox just chooses a
> > better-contrasting foreground color).
>
> I agree with your points, it would be best to address this issue before
> shipping accent-color. I'll post some updates in the github issue so we
> can try to converge on the same behavior.

Thank you, that's great to hear :)

--Emilio

> On Wed, Jun 9, 2021 at 2:14 AM Emilio Cobos Álvarez <emi...@mozilla.com
> <mailto:emi...@mozilla.com>> wrote:
>
> Hi Joey,
>
> https://github.com/w3c/csswg-drafts/issues/6159
> <https://github.com/w3c/csswg-drafts/issues/6159> is still open, and
> it'd
> be nice to address since one of the proposals involves changing the
> syntax of the property to take multiple colors.
>
> If I recall correctly, the way the Chromium implementation of this
> property works right now is switching to "dark mode" form controls for
> certain accent color values which you consider as not having enough
> contrast.
>
> I don't think that's a great way to go around it, as choosing slightly
> different colors dramatically changes the appearance of the
> controls. It
> feels also weird that accent-color would "trump" the color-scheme
> property.
>
> On 6/9/21 03:57, Joey Arhar wrote:
> >
> >         Contact emails
> >
> > jar...@chromium.org <mailto:jar...@chromium.org>

> <mailto:jar...@chromium.org <mailto:jar...@chromium.org>>

>  <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>>?

> >
> > Yes
> >
> >
> >         Tracking bug
> >
> > https://bugs.chromium.org/p/chromium/issues/detail?id=1092093
> <https://bugs.chromium.org/p/chromium/issues/detail?id=1092093>
> > <https://bugs.chromium.org/p/chromium/issues/detail?id=1092093
> <https://bugs.chromium.org/p/chromium/issues/detail?id=1092093>>
> >
> >
> >         Launch bug
> >
> > https://bugs.chromium.org/p/chromium/issues/detail?id=1193835
> <https://bugs.chromium.org/p/chromium/issues/detail?id=1193835>
> > <https://bugs.chromium.org/p/chromium/issues/detail?id=1193835
> <https://bugs.chromium.org/p/chromium/issues/detail?id=1193835>>
> >
> >
> >         Link to entry on the Chrome Platform Status
> >
> > https://chromestatus.com/feature/4752739957473280
> <https://chromestatus.com/feature/4752739957473280>
> > <https://chromestatus.com/feature/4752739957473280
> <https://chromestatus.com/feature/4752739957473280>>
> >
> >
> >         Links to previous Intent discussions
> >
> > Intent to prototype:
> >
> https://groups.google.com/a/chromium.org/g/blink-dev/c/q9zf-frdewo/m/zxw2HuzGAQAJ
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/q9zf-frdewo/m/zxw2HuzGAQAJ>
>
> >
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/q9zf-frdewo/m/zxw2HuzGAQAJ
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/q9zf-frdewo/m/zxw2HuzGAQAJ>>
> >
> >
> > This intent message was generated by Chrome Platform Status

> > <https://www.chromestatus.com/ <https://www.chromestatus.com/>>.

> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "blink-dev" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to blink-dev+...@chromium.org

> <mailto:blink-dev%2Bunsu...@chromium.org>
> > <mailto:blink-dev+...@chromium.org
> <mailto:blink-dev%2Bunsu...@chromium.org>>.

> > To view this discussion on the web visit
> >
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKRHr0arTSU6sTq_nLGrf4oxw9g-8YCMB38Yk7EeZDKSg%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKRHr0arTSU6sTq_nLGrf4oxw9g-8YCMB38Yk7EeZDKSg%40mail.gmail.com>
>
> >

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKRHr0arTSU6sTq_nLGrf4oxw9g-8YCMB38Yk7EeZDKSg%40mail.gmail.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKRHr0arTSU6sTq_nLGrf4oxw9g-8YCMB38Yk7EeZDKSg%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to blink-dev+...@chromium.org

> <mailto:blink-dev%2Bunsu...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aabe9f68-6df3-01ab-e5d2-372ef19e4492%40mozilla.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aabe9f68-6df3-01ab-e5d2-372ef19e4492%40mozilla.com>.
>

[Emilio Cobos Álvarez]

On 6/10/21 01:54, Mason Freed wrote:
> Just adding a few comments here, since I was involved in the original
> spec discussions for this feature:
>
> On Wednesday, June 9, 2021 at 12:35:23 PM UTC-7 Joey Arhar wrote:
>
> > Also there are just a few tests, I guess this is something tricky to
> > test in WPT. Anyway should we check it applies to more elements than
> > just checkbox?
>

> I have a bunch of pixel tests internal to chromium here
> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/fast/forms/accent-color/;drc=b7ed0ab024e0ebb4d23cdad80339890417bd48da>.

> As for which elements it applies to, I think this might vary between
> browsers and isn't specified by the spec. For example, WebKit
> already uses the MacOS system preferences accent color setting to
> color checkboxes and radios, but it does not do the same for <input
> type=range> and <progress> like I implemented in Chromium. I could
> easily imagine WebKit implementing this for checkboxes and radios
> but nothing else, and again, the spec doesn't say... there may have
> been more discussion about this in spec issues and CSSWG that I
> missed though.
>
>
> This was definitely discussed, and there were strong opinions that the
> spec should be decidedly quiet on where and how to apply the
> accent-color. Several people represented the view that implementations
> should be allowed (and encouraged) to innovate on form controls, without
> constraints from this feature. To that end, there can be no WPT tests
> for the visual appearance of any form control anyway, but definitely not
> for accent-color.
>
>
> Emilio's comments about interop make me feel like maybe we should
> specify which elements it applies to though, even if WebKit doesn't
> end up implementing all of them...? I'm open to suggestions here.
>
>
> Again here, my original proposal

> <https://github.com/mfreed7/accent-color/blob/master/proposal.md> had

> non-normative guidance for how to use accent-color on each control, but
> CSSWG disagreed with that. The (rough) consensus was to leave the
> application of accent-color up to the implementations. WebKit was a
> strong proponent of *not* specifying which elements to style, or how to
> style them.
>
> > I don't think that's a great way to go around it, as choosing
> slightly
> > different colors dramatically changes the appearance of the
> controls. It
> > feels also weird that accent-color would "trump" the color-scheme
> property.
>
>
> Emilio, can you clarify how Firefox went about implementing the
> requirement that the "UA must maintain contrast for legibility of the
> control"? The way this is implemented in Chromium (roughly) guarantees a
> minimum contrast. We do agree that it is abrupt and not ideal, but we're
> not sure how else we could implement this. Again, having the author
> provide two colors would have been so much more straightforward. But
> given the spec, I think something along the lines of what we've
> implemented is about as good as it's going to get. Ideas appreciated! If
> the Firefox algorithm is simple enough, perhaps we can use the same
> algorithm. And think about specifying it.
>
> One point of clarification: accent-color doesn't "trump" the
> color-scheme in all cases. It only does so when the current color-scheme
> and the current accent-color don't provide enough contrast.

So the way form controls are drawn on Firefox requires two colors, a
"background" color (the accent color), and a "foreground" color (a color
that has sufficient contrast with the accent color). All other
decorative colors are derived from the accent color, by tweaking the
luminance.

For native form controls, the foreground and background colors are
provided by the OS (the macOS accent color, the Linux theme accent
color, etc). On Windows and Android it's hard-coded to white-on-blue,
though you can use the OS accent color if you change
`widget.non-native-theme.use-theme-accent` to true).

For the accent-color property, as specified it only requires one color
(the accent color), so we just choose a white or black foreground
depending on whether the color is "dark enough":


https://searchfox.org/mozilla-central/rev/2c991232499e826e46f9d976eb653817340ba389/widget/nsNativeBasicTheme.cpp#192-197

Note that we always blend the accent color with white to make sure it's
opaque.

Anyhow, I think the current approach is not great, but is as good as it
can get with only one color. I think it's slightly unfortunate as some
accent colors would still look better with white, and the authors could
want e.g., a checkmark that isn't white or black. That's why I think the
option of providing two colors (background and foreground) to the
property is best.

-- Emilio

> <mailto:jar...@chromium.org <mailto:jar...@chromium.org>>

>  <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>>?

> >
> > Yes
> >
> >
> >         Tracking bug
> >
> > https://bugs.chromium.org/p/chromium/issues/detail?id=1092093
> <https://bugs.chromium.org/p/chromium/issues/detail?id=1092093>
> >
> <https://bugs.chromium.org/p/chromium/issues/detail?id=1092093
> <https://bugs.chromium.org/p/chromium/issues/detail?id=1092093>>
> >
> >
> >         Launch bug
> >
> > https://bugs.chromium.org/p/chromium/issues/detail?id=1193835
> <https://bugs.chromium.org/p/chromium/issues/detail?id=1193835>
> >
> <https://bugs.chromium.org/p/chromium/issues/detail?id=1193835
> <https://bugs.chromium.org/p/chromium/issues/detail?id=1193835>>
> >
> >
> >         Link to entry on the Chrome Platform Status
> >
> > https://chromestatus.com/feature/4752739957473280
> <https://chromestatus.com/feature/4752739957473280>
> > <https://chromestatus.com/feature/4752739957473280
> <https://chromestatus.com/feature/4752739957473280>>
> >
> >
> >         Links to previous Intent discussions
> >
> > Intent to prototype:
> >
> https://groups.google.com/a/chromium.org/g/blink-dev/c/q9zf-frdewo/m/zxw2HuzGAQAJ
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/q9zf-frdewo/m/zxw2HuzGAQAJ>
>
> >
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/q9zf-frdewo/m/zxw2HuzGAQAJ
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/q9zf-frdewo/m/zxw2HuzGAQAJ>>
> >
> >
> > This intent message was generated by Chrome Platform Status

> > <https://www.chromestatus.com/ <https://www.chromestatus.com/>>.

> >
> > --
> > You received this message because you are subscribed to the
> Google
> > Groups "blink-dev" group.
> > To unsubscribe from this group and stop receiving emails from
> it, send

> > an email to blink-dev+...@chromium.org
> <mailto:blink-dev%2Bunsu...@chromium.org>
> > <mailto:blink-dev+...@chromium.org

> <mailto:blink-dev%2Bunsu...@chromium.org>>.

> > To view this discussion on the web visit
> >
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKRHr0arTSU6sTq_nLGrf4oxw9g-8YCMB38Yk7EeZDKSg%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKRHr0arTSU6sTq_nLGrf4oxw9g-8YCMB38Yk7EeZDKSg%40mail.gmail.com>
>
> >

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKRHr0arTSU6sTq_nLGrf4oxw9g-8YCMB38Yk7EeZDKSg%40mail.gmail.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKRHr0arTSU6sTq_nLGrf4oxw9g-8YCMB38Yk7EeZDKSg%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
>
> --
> You received this message because you are subscribed to the
> Google Groups "blink-dev" group.
>
> To unsubscribe from this group and stop receiving emails from

> it, send an email to blink-dev+...@chromium.org
> <mailto:blink-dev%2Bunsu...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aabe9f68-6df3-01ab-e5d2-372ef19e4492%40mozilla.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aabe9f68-6df3-01ab-e5d2-372ef19e4492%40mozilla.com>.
>

[Joey Arhar]

Thanks for the explanation Emilio! I responded here: https://github.com/w3c/csswg-drafts/issues/6159#issuecomment-858737718

> It'd be better to request an official position, but I personally don't

> object to ship it if the interop situation is reasonable.

Done: https://github.com/mozilla/standards-positions/issues/540

> One point of clarification: accent-color doesn't "trump" the color-scheme in all cases. It only does so when the current color-scheme and the current accent-color don't provide enough contrast.

+1, we can even adjust the desired contrast ratio to make this happen less often. We currently have it set to 3 because... I don't know? I can see 3:1 minimum contrast ratio guidance here on web.dev.

[Mason Freed]

On Thu, Jun 10, 2021 at 7:34 AM Emilio Cobos Álvarez <emi...@mozilla.com> wrote:

So the way form controls are drawn on Firefox requires two colors, a
"background" color (the accent color), and a "foreground" color (a color
that has sufficient contrast with the accent color). All other
decorative colors are derived from the accent color, by tweaking the
luminance.

For native form controls, the foreground and background colors are
provided by the OS (the macOS accent color, the Linux theme accent
color, etc). On Windows and Android it's hard-coded to white-on-blue,
though you can use the OS accent color if you change
`widget.non-native-theme.use-theme-accent` to true).

For the accent-color property, as specified it only requires one color
(the accent color), so we just choose a white or black foreground
depending on whether the color is "dark enough":


https://searchfox.org/mozilla-central/rev/2c991232499e826e46f9d976eb653817340ba389/widget/nsNativeBasicTheme.cpp#192-197

Note that we always blend the accent color with white to make sure it's
opaque.

Anyhow, I think the current approach is not great, but is as good as it
can get with only one color. I think it's slightly unfortunate as some
accent colors would still look better with white, and the authors could
want e.g., a checkmark that isn't white or black. That's why I think the
option of providing two colors (background and foreground) to the
property is best.

Thanks for the explanation and link to the code. That's super helpful. It looks like the Gecko approach is actually quite similar to the Chromium one. The IsDarkColor() function just looks at the equal-weighted average of raw RGB components and decides "dark" if it is <0.5. And then it uses pure white or pure black as the contrasting color. The Chromium approach differs in two ways. As Joey said, we use UX-picked "dark" and "light" colors, which are close to black/white, but not identical. And it actually computes the proper contrast ratio between the accent color and each of these colors, to ensure we get the maximum contrast choice, rather than just using averaged RGB components.

From my point of view, both of these approaches meet the letter of the spec, and are likely to be close in actual behavior.  

[David Baron]

On Thu, Jun 10, 2021 at 9:42 AM Mason Freed <mas...@chromium.org> wrote:

Thanks for the explanation and link to the code. That's super helpful. It looks like the Gecko approach is actually quite similar to the Chromium one. The IsDarkColor() function just looks at the equal-weighted average of raw RGB components and decides "dark" if it is <0.5. And then it uses pure white or pure black as the contrasting color. The Chromium approach differs in two ways. As Joey said, we use UX-picked "dark" and "light" colors, which are close to black/white, but not identical. And it actually computes the proper contrast ratio between the accent color and each of these colors, to ensure we get the maximum contrast choice, rather than just using averaged RGB components.

It's worth emphasizing that this distinction is pretty significant because the contributions of the red, green, and blue color channels in sRGB to perceived luminosity are *very* different.  The contributions are 71.54% from the green channel, 21.25% from the red channel, and 7.21% from the blue channel!  (Note that those need to be linear-light values, i.e., un-gamma-corrected.)  These numbers show up in a number of Web specifications, such as the definition of luminanceToAlpha in SVG or in the middle row of the matrix in lin_sRGB_to_XYZ() in css-color-4.  The WAI rules for computing color contrast ratios (see relative luminance definition) use very slightly different numbers but I suspect these may be part of the issue about use of some values from an outdated version of sRGB (although I'm not sure).

I suspect it's likely a good idea to fix the Gecko code in this case.

-David

[David Baron]

Oops, sorry, it's actually the SVG numbers that slightly disagree with the other two, which I suspect are the correct ones (71.52% green, 21.26% red, 7.22% blue).  Though I'm not sure, but either set is probably close enough.

-David

[Yoav Weiss]

Hey folks! Could you provide some clarity on the interop situation here? There are multiple threads, so a summary would be nice :)

[Joey Arhar]

Sorry for the delay, I was out last week.

Here is a summary of the interop situation, among other things:

WebKit hasn't replied to my request for position. I suspect that if they were to implement accent-color, it would only be for type=radio and type=checkbox since they don't already have any colors for type=range or progress.

Mozilla hasn't replied to my request for position, but Emilio has already implemented the feature in firefox nightly.

The discussions in this thread, as well as the github thread, are revolving around what exactly to do in order to guarantee contrast. You can see the exact difference between firefox and chrome in these screenshots - we don't currently exactly agree on where to flip the color-scheme to ensure contrast, as you can see in the screenshots. Earlier in this thread, Emilio suggested that they should be the same in order for them to be interoperable:

> As implemented right now in Chromium and Gecko, some websites would have

> pretty different form controls depending on which accent color is
> chosen, because we have different thresholds in order to consider
> something having little contrast, and Chrome auto-switches to dark mode
> controls if that happens (while Firefox just chooses a

> better-contrasting foreground color).

I wouldn't mind tweaking the chrome behavior slightly in order for them to be the same after shipping, but Emilio also hasn't replied to my comparison images yet.

There is also the consideration of having multiple colors provided to accent-color versus only using one, which Emilio mentioned earlier in this thread. I find it unlikely that we will change to multiple colors since this was already deliberated in CSSWG and we ended up with one color, as well as strong arguments in the github thread by tabatkins and fantasai.

[Yang Guo]

Is there any special consideration regarding debuggability necessary? We should at the least make sure that this new CSS property shows up correctly in DevTools and the color picker works in combination with it. Please also refer to https://goo.gle/devtools-checklist

[Joey Arhar]

Support for accent-color was added in the DevTools frontend here: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2759547

Here is a picture of the color picker, it appears to work great!

[Joey Arhar]

I have closed the CSSWG issue I referenced before in this thread - I don't think that we are likely to go back and change accent-color to allow multiple colors, and I'd be happy to tweak the color-scheme flipping threshold after shipping this feature in order to improve interop as Emilio mentioned earlier in this thread.

[Manuel Rego]

LGTM1

I see this was re-discussed past week on the CSSWG and the resolution was still to keep just 1 color for this property.

It's nice that you're willing to tweak the color flipping threshold to improve interop if needed.

[Daniel Bratell]

LGTM2

/Daniel

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9a27ab88-da84-4f3c-9184-37540d381a1bn%40chromium.org.

[Mike West]

LGTM3.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bcca7c09-9632-9164-ac86-f92a54498de2%40gmail.com.

[Tyler H]

Hi, is there any intent to add alpha channel support to this property? Firefox allows transparency in RGBA values but Chromium browsers currently do not. Compare this demo in Firefox vs Chrome or Edge to see what I mean:

https://jsfiddle.net/TylerH/jvbznms5/

[Joey Arhar]

> Hi, is there any intent to add alpha channel support to this property? Firefox allows transparency in RGBA values but Chromium browsers currently do not.

Thanks for the feedback! I explicitly disabled support for alpha due to this bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1200932

I'd be happy to revisit if there is a way to avoid the bug and support your use case, especially if Firefox currently fulfills this. I'll start commenting on the bug, please post any further discussion and questions about this there.