Intent to Implement and Ship: CSS Color Adjust: Remove 'only' and support used 'dark' for preferred 'light' for color-scheme

140 views
Skip to first unread message

Rune Lillesveen

unread,
May 28, 2020, 5:47:42 AM5/28/20
to blink-dev
The color-scheme property from CSS Color Adjustment level 1 spec changed in two ways. 1. The 'only' keyword is no longer special and is treated as a <custom-ident> as any other unknown color-scheme. The 'only' keyword was previously only allowed in combination with 'light', but had otherwise no effect in Chrome. 2. 'color-scheme: dark' will have a used value of 'dark' even when the preferred color-scheme is 'light'. 'color-scheme: light dark' still has a used value based on the preferred scheme. The spec has changed which allows page authors to use dark themed UA rendering even when the preferred color-scheme is 'light'. The new behavior is: color-scheme: light -> always light color-scheme: dark -> always dark color-scheme: light dark -> select the preferred scheme This means content which always has a dark theme in their CSS will be able to match that with dark themed UA controls. It also improves interoperability with WebKit which already had this behavior for 'color-scheme: dark'.
Aligns with WebKit. There is an interoperability risk not to ship this. Compatibility: For 'only': the parser will be more admissive and allow color-scheme with 'only' where we previously would drop the declaration. For instance this will now be accepted with only being ignored as an unknown color-scheme: color-scheme: light dark only For 'color-scheme: dark': Previously this was equivalent to 'color-scheme: light dark' in Chrome. There is a chance that authors who want to support both light and dark have used this as a pattern. However, the current effect is limited since we have not yet shipped dark themed UA controls, only initial color and default viewport background. Firefox: Mixed public signals Mozilla were originally opposed to support a used 'dark' value when the preferred scheme was 'light' because user agents using system form control rendering would not be able to use dark themed controls when the system preference was a light, which led to the spec originally being written as it was. The plan for Firefox is to move away from system controls: https://github.com/w3c/csswg-drafts/issues/3881#issuecomment-634463620 From the CSSWG meeting notes for this resolution: "emilio: uneasy about overwriting user preference. Not really objecting" Edge: No public signals (but fremy@ argued for this when the color-scheme property was initially introduced. The use case mentioned was applications like VS Code which is typically dark when the OS theme is light and would benefit from being able to have dark themed controls).
Safari: Shipped 'only' still has a separate meaning in Safari for opting out of UA color transformations. Web developers: No signals Limited usefulness before CSSColorSchemeUARendering is enabled.
Yes Yes As part of shipping this, existing tests in wpt css/css-color-adjust will be modified to match the current spec draft. https://crbug.com/1087115 https://chromestatus.com/feature/5653721679659008
This intent message was generated by Chrome Platform Status.

PhistucK

unread,
May 28, 2020, 6:51:16 AM5/28/20
to Rune Lillesveen, blink-dev
Sounds like even after this change, there will still not be 100% interoperability with Safari, or did I misunderstand?
The risks section is quite confusing.

☆PhistucK


--
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/CACuPfeTMg3-RVWOKRnKQ7OTzbHcLXpVoVrVdRGO6Kr-x6XhBAw%40mail.gmail.com.

Chris Harrelson

unread,
Jun 4, 2020, 3:10:28 PM6/4/20
to PhistucK, Rune Lillesveen, blink-dev
LGTM1

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_KZ34VfewpFpvGab-_JOOfjSEQ26HvFV-NR9JL4L-SY_Q%40mail.gmail.com.

Mike West

unread,
Jun 4, 2020, 3:58:25 PM6/4/20
to blink-dev, phis...@gmail.com, fut...@chromium.org
LGTM2. The web-facing behavior seems like a clear interop improvement.

That said, I'd also appreciate a clarification regarding the delta between Safari's support for `only` and Chromium's.

-mike

On Thursday, June 4, 2020 at 9:10:28 PM UTC+2, Chris Harrelson wrote:
LGTM1

On Thu, May 28, 2020 at 3:51 AM PhistucK <phis...@gmail.com> wrote:
Sounds like even after this change, there will still not be 100% interoperability with Safari, or did I misunderstand?
The risks section is quite confusing.

☆PhistucK


On Thu, May 28, 2020 at 12:47 PM Rune Lillesveen <fut...@chromium.org> wrote:
The color-scheme property from CSS Color Adjustment level 1 spec changed in two ways. 1. The 'only' keyword is no longer special and is treated as a <custom-ident> as any other unknown color-scheme. The 'only' keyword was previously only allowed in combination with 'light', but had otherwise no effect in Chrome. 2. 'color-scheme: dark' will have a used value of 'dark' even when the preferred color-scheme is 'light'. 'color-scheme: light dark' still has a used value based on the preferred scheme. The spec has changed which allows page authors to use dark themed UA rendering even when the preferred color-scheme is 'light'. The new behavior is: color-scheme: light -> always light color-scheme: dark -> always dark color-scheme: light dark -> select the preferred scheme This means content which always has a dark theme in their CSS will be able to match that with dark themed UA controls. It also improves interoperability with WebKit which already had this behavior for 'color-scheme: dark'.
Aligns with WebKit. There is an interoperability risk not to ship this. Compatibility: For 'only': the parser will be more admissive and allow color-scheme with 'only' where we previously would drop the declaration. For instance this will now be accepted with only being ignored as an unknown color-scheme: color-scheme: light dark only For 'color-scheme: dark': Previously this was equivalent to 'color-scheme: light dark' in Chrome. There is a chance that authors who want to support both light and dark have used this as a pattern. However, the current effect is limited since we have not yet shipped dark themed UA controls, only initial color and default viewport background. Firefox: Mixed public signals Mozilla were originally opposed to support a used 'dark' value when the preferred scheme was 'light' because user agents using system form control rendering would not be able to use dark themed controls when the system preference was a light, which led to the spec originally being written as it was. The plan for Firefox is to move away from system controls: https://github.com/w3c/csswg-drafts/issues/3881#issuecomment-634463620 From the CSSWG meeting notes for this resolution: "emilio: uneasy about overwriting user preference. Not really objecting" Edge: No public signals (but fremy@ argued for this when the color-scheme property was initially introduced. The use case mentioned was applications like VS Code which is typically dark when the OS theme is light and would benefit from being able to have dark themed controls).
Safari: Shipped 'only' still has a separate meaning in Safari for opting out of UA color transformations. Web developers: No signals Limited usefulness before CSSColorSchemeUARendering is enabled.
Yes Yes As part of shipping this, existing tests in wpt css/css-color-adjust will be modified to match the current spec draft. https://crbug.com/1087115 https://chromestatus.com/feature/5653721679659008
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+unsubscribe@chromium.org.

--
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.

Rune Lillesveen

unread,
Jun 5, 2020, 7:10:28 AM6/5/20
to PhistucK, blink-dev
On Thu, May 28, 2020 at 12:51 PM PhistucK <phis...@gmail.com> wrote:
Sounds like even after this change, there will still not be 100% interoperability with Safari, or did I misunderstand?
The risks section is quite confusing.

There are a bunch of issues with the Safari implementation. Two of the issues below. The serialization for getComputedStyle is also not spec compliant, which in addition to 'auto' vs 'normal' makes a lot of the wpt tests fail in Safari.


The interop improvement with this change is for the valid light/dark combinations mentioned in the Motivation section.

The 'only' having a separate meaning in Safari is for opting out of forced darkening which is currently out of scope for the specification. This is for apps [3]. It might be an idea to unify the way of opting out of forced darkening for Android and iOS apps and have this is the spec as discussed in [2], but I don't think that should block this intent.

See:

Daniel Bratell

unread,
Jun 5, 2020, 9:56:10 AM6/5/20
to Rune Lillesveen, PhistucK, blink-dev

LGTM3

/Daniel

Emilio Cobos Álvarez

unread,
Jun 5, 2020, 10:10:47 AM6/5/20
to Rune Lillesveen, blink-dev
That resolution was on the assumption that the prefers-color-scheme's
no-preference value would go away as resolved in [1].

Is there any intention to change that as well anytime soon? Asking
because at least to me both resolutions seem related, and it'd be sad to
leave the spec in a state where it makes sense, but where
implementations don't, or vice versa.

-- Emilio

[1]: https://github.com/w3c/csswg-drafts/issues/3857

On 5/28/20 11:47 AM, Rune Lillesveen wrote:
> Contact emails futhark@chromium <mailto:futhark@chromium> Design
> viewport background. /Firefox/: Mixed public signals Mozilla were
> originally opposed to support a used 'dark' value when the preferred
> scheme was 'light' because user agents using system form control
> rendering would not be able to use dark themed controls when the system
> preference was a light, which led to the spec originally being written
> as it was. The plan for Firefox is to move away from system controls:
> https://github.com/w3c/csswg-drafts/issues/3881#issuecomment-634463620
> <https://github.com/w3c/csswg-drafts/issues/3881#issuecomment-634463620>
> From the CSSWG meeting notes for this resolution: "emilio: uneasy about
> overwriting user preference. Not really objecting" /Edge/: No public
> signals (but fremy@ argued for this when the color-scheme property was
> initially introduced. The use case mentioned was applications like VS
> Code which is typically dark when the OS theme is light and would
> benefit from being able to have dark themed controls).
> /Safari/: Shipped 'only' still has a separate meaning in Safari for
> opting out of UA color transformations. /Web developers/: No signals
> Activation Limited usefulness before CSSColorSchemeUARendering is enabled.
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature
> fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
> Yes As part of shipping this, existing tests in wpt css/css-color-adjust
> will be modified to match the current spec draft. Tracking bug
> https://crbug.com/1087115 <https://crbug.com/1087115> Link to entry on
> the Chrome Platform Status
> https://chromestatus.com/feature/5653721679659008
> <https://chromestatus.com/feature/5653721679659008>
> 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/CACuPfeTMg3-RVWOKRnKQ7OTzbHcLXpVoVrVdRGO6Kr-x6XhBAw%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeTMg3-RVWOKRnKQ7OTzbHcLXpVoVrVdRGO6Kr-x6XhBAw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

Emilio Cobos Álvarez

unread,
Jun 5, 2020, 10:12:14 AM6/5/20
to Rune Lillesveen, blink-dev
On 6/5/20 4:10 PM, Emilio Cobos Álvarez wrote:
> That resolution was on the assumption that the prefers-color-scheme's
> no-preference value would go away as resolved in [1].
>
> Is there any intention to change that as well anytime soon? Asking
> because at least to me both resolutions seem related, and it'd be sad to
> leave the spec in a state where it makes sense, but where
> implementations don't, or vice versa.

(It was kinda implicit, but I'd be happy to make Gecko follow suit if so)

Rune Lillesveen

unread,
Jun 5, 2020, 1:11:01 PM6/5/20
to Emilio Cobos Álvarez, blink-dev
On Fri, Jun 5, 2020 at 4:10 PM Emilio Cobos Álvarez <emi...@mozilla.com> wrote:
That resolution was on the assumption that the prefers-color-scheme's
no-preference value would go away as resolved in [1].

Is there any intention to change that as well anytime soon? Asking
because at least to me both resolutions seem related, and it'd be sad to
leave the spec in a state where it makes sense, but where
implementations don't, or vice versa.

Thanks, I wasn't aware of that resolution. I will prepare an intent for that as well.

Reply all
Reply to author
Forward
0 new messages