Intent to Ship: Forced Colors Mode

592 views
Skip to first unread message

Alison Maher

unread,
Apr 30, 2020, 4:02:46 PM4/30/20
to blin...@chromium.org, Rossen Atanassov

Contact emails

Rossen.A...@microsoft.com, Alison...@microsoft.com 


Explainer

High Contrast Explainer


Spec

Forced Colors Mode Spec


Forced Colors Mode wasn’t considered a candidate for TAG review and was directly worked on by the CSS Working Group. This is a user facing feature which provides some developer control that has been in flight for a decade now. The functionality has been available in Internet Explorer and Legacy Microsoft Edge behind '-ms-high-contrast' and '-ms-high-contrast-adjust' properties, thus making 'forced-colors' and 'forced-color-adjust' merely aliases of the formerly available properties.


Summary

Forced Colors Mode is currently only supported on Windows through the Windows High Contrast feature. High Contrast was first introduced as a Windows accessibility feature for individuals who need visual help due to vision problems or poor light environments. The goal is to increase text readability for such individuals by guaranteeing high color contrast (>10:1) between the text and background, while at the same time reducing cognitive overload through a simplified color palette.

 

Applications such as the browser can make use of such color themes by propagating them into their web content model. In such implementations, the High Contrast colors are propagated to the website content as a set of user agent style overrides, thus increasing the readability of the web content with guaranteed text to background contrast ratios.


Link to “Intent to Prototype” blink-dev discussion

Intent to Implement


Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes, Forced Colors Mode is supported on all Blink platforms. For now, though, it is only activatable on Windows through a user-chosen High Contrast Theme.


Demo link

This feature would apply Forced Colors Mode styles to every web page and can be demonstrated by toggling the Windows High Contrast presentation condition (Windows Start > Settings > Ease of Access > High contrast > Turn on High Contrast).


Debuggability

Forced Colors Mode styles and properties can be debugged in DevTools. DevTools UI support for Forced Colors Mode is underway and can be tracked here.


A proposed addition to DevTools support is a Forced Colors Mode emulation feature. When toggled, this would allow developers to debug their page in a simulated High Contrast environment on non-Windows devices. This, however, is a future proposal.


Risks

Interoperability and Compatibility

High Contrast theming is currently only available on the Windows platform. Internet Explorer and Legacy Microsoft Edge supported this behind vendor prefixed properties. The popularity of this feature has attracted top sites such as Facebook, YouTube, Microsoft Office, etc. to take dependencies on the vendor prefixed behavior.


These vendor prefixed properties, while still supported in Microsoft Edge for backwards compatibility, are not supported in the current Chromium implementation. We plan to deprecate the legacy prefixes as soon as the standard Forced Colors Mode feature ships everywhere.


Edge: Shipped

Firefox: Shipped - using a browser setting (missing CSS property and MQ support)

Safari: No signals

Web / Framework developers: Positive


Ergonomics

If Forced Colors Mode is enabled at the same time as another color scheme, Forced Colors Mode will override the effects of those color schemes.


For example, if a user has enabled Dark Mode and then sets their Windows High Contrast Theme to black-on-white, ‘prefers-color-scheme’ will evaluate to match the closest Windows High Contrast colors (light in this example), rather than continuing to match the original Dark Mode Theme (dark).


Activation

The main feedback received from developers is that it is difficult to adjust Forced Colors Mode styles for individual elements rather than for an entire subtree of elements. This is currently being discussed by the CSSWG.


Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Yes, this feature is tested by web-platform tests.

  • Web tests for the ‘forced-color-adjust’ property.

  • Web tests for the ‘forced-colors’ media query.

  • Web tests for the Forced Colors Mode feature. These appear as failing because they must be run inside of a virtual test suite that simulates High Contrast to pass.


Entry on the feature dashboard

https://www.chromestatus.com/feature/5757293075365888

Stephen Mcgruer

unread,
Apr 30, 2020, 4:32:33 PM4/30/20
to Alison Maher, blin...@chromium.org, Rossen Atanassov
These appear as failing because they must be run inside of a virtual test suite that simulates High Contrast to pass.

Hi Alison; have you explored whether WPT could support these tests upstream, perhaps via a webdriver API? Scanning the spec I could imagine an API that set forced colors mode and also set the users color palette (to avoid the OS-dependent part there). Happy to chat off-thread about this to avoid spamming blink-dev; myself and the rest of the team at ecosyst...@chromium.org are always happy to help folks make WPT cover more of the web! :)

--
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/SN6PR00MB0416DEC17DB005015918F19F8AAA0%40SN6PR00MB0416.namprd00.prod.outlook.com.

Alison Maher

unread,
Apr 30, 2020, 4:57:58 PM4/30/20
to Stephen Mcgruer, blin...@chromium.org, Rossen Atanassov
Hi Stephen - I hadn't considered that previously, but thanks for the suggestion. Based on an initial glance, that seems like it could be a good option to pursue. To avoid extra noise, I'll follow up in an off-thread to discuss further.

From: Stephen Mcgruer <smcg...@chromium.org>
Sent: Thursday, April 30, 2020 1:32 PM
To: Alison Maher <Alison...@microsoft.com>
Cc: blin...@chromium.org <blin...@chromium.org>; Rossen Atanassov <Rossen.A...@microsoft.com>
Subject: [EXTERNAL] Re: [blink-dev] Intent to Ship: Forced Colors Mode
 

Anders Hartvoll Ruud

unread,
Apr 30, 2020, 7:06:52 PM4/30/20
to Alison Maher, blin...@chromium.org, Rossen Atanassov
Rant time.

The biggest thing I don't like about this spec is that it's attempting to 'revert' at computed-value time, which I really think shouldn't be allowed. We risk running into a circularity at some point, since computing 'forced-color-adjust' requires cascading, yet its computed value affects how things cascade. (Yes, css-logical has a similar problem, which is not a convincing argument for making things worse). It's not a huge problem in practice, since the properties being reverted don't really affect other properties currently.

But imagine if forced colors mode wanted to do 'font-size:revert' (which doesn't make sense, but let's say that it did):

@property --x {
  syntax: "<length>";
  inherits: false;
  initial-value: 0px;
}

div {
  font-size: 20px;
  --x: 10em;
  forced-color-adjust: var(--x);
}


In order to know the computed value of 'forced-color-adjust' in this example, we must first compute '--x'. This contains 'em' units, which means the computed value of 'font-size' needs to be known. The computed value of 'font-size' is obviously '20px', which makes the computed value of '--x' 200px. When substituted into forced-color-adjust, we get forced-color-adjust:200px, which doesn't parse for that property, hence it becomes invalid at computed-value time, and is treated as unset (which becomes auto in this case).

Now the forced colors mode wants to revert font-size back to the UA-style (e.g. 16px), but the computed value of font-size has already been determined at 20px. Worse, its previously computed value had side effects: --x has a computed value of 200px, which would no longer be correct if font-size is reverted after its value is computed. Reverting font-size alone will not be enough to undo the "damage" done by the temporary and ultimately incorrect computed value of font-size. This is a bad situation.

To reiterate, the spec doesn't revert any properties that other properties depend on, so it doesn't exhibit this bad behavior currently. But it seems like it very easily could in the future, if we were to e.g. change how colors work. And in general I wanted to highlight why I think reverting at computed-value time isn't great.

I'm apparently the only one concerned about this (my spec issue on this was met with a shrug), so probably not something to block the intent, but I thought it should be mentioned.

(Rant ends).

Perhaps more actionable feedback:

 - The spec has diverged from the Blink implementation. (The Blink implementation was more or less accurate at some point, but not anymore). Most notably the spec now says to revert in the author origin, which means reverting back to the user level. We're currently reverting back to the UA level. (Easy to fix).
 - The spec now mentions that on "user input controls (except button-like controls)", background-image should be reverted. We don't do this AFAICT.
 - The background-color should now be forced to different things depending on what the computed value of color is. We don't do this either.
 - The spec says "if color is a system color", but the computed value of color can't really "be" a system color, can it? The computed value is rgb(...), without any "system origin". Spec should clarify.
 - Should forced-colors-mode automatically disable the 'appearance' of widgets? (And does the current behavior match what we want)?


--

Emilio Cobos Álvarez

unread,
Apr 30, 2020, 11:40:12 PM4/30/20
to Anders Hartvoll Ruud, Alison Maher, blin...@chromium.org, Rossen Atanassov
FWIW, I had missed Anders' issue, but the concern is legit. These kind
of property interactions are always a bit annoying.

These are the ones I know of:

* font-size: special because of em / rem / ex / ch units.
* font-{weight,style,stretch,family}: special because of ex / ch units.
* writing-mode,text-orientation,direction: special because of logical
properties.
* (not implemented anywhere, and with issues [1]) line-height: special
because of lh / rlh units.

(BTW, a bit suprising that P&V only deals with font-size/line-height...
But maybe others are not an issue as you cannot create a value depending
on them _and_ affecting other lengths too... Haven't thought it through,
late here).

Firefox implements something similar to forced colors, but doesn't
implement forced-color-adjust / any opt-out mechanism.

In theory forced-color-adjust (while unfortunate in the sense Anders
points out) is not problematic as long as it doesn't interact with any
of those. It does interact with a lot of properties that even though
they're not magical yet, could in theory become magical one day, and
this property would prevent / over-complicate that...

That being said, my biggest concern with Blink shipping this right now
is that it's not clear if forced-color-adjust is the thing authors
actually need to properly control forced colors.

I'm personally not fully convinced that allowing authors to override
forced-colors is good to begin with (it allows authors to shoot
themselves in the foot and harm users that need readability the most).

But if we need it, it seems like an inherited property that affects all
colors on all the subtree is not necessarily the best... It seems
perfectly reasonable to say "I want this foreground / background color
even in forced colors, but I don't care what you do to my e.g. border
colors, or the colors of my descendants".

Microsoft did propose a way to have more fine-grained control over the
declarations that were reverted[2], but that concrete proposal is also
quite a layering violation IMO.

I was tinkering with proposing a separate value for forced-color-adjust
that didn't automatically inherit, or such, in the way user-select or
such are specified to work (where the property doesn't inherit, and the
"auto" value inherits from the parent). That'd allow you to override
forced-colors per element, though it'd still have the issue Anders
points out. Also, it might not be good enough, it seems you probably
want per-declaration granularity...

So maybe something in the value space would be a better override,
instead of the forced-color-adjust property? Like an argument to the
color() function that prevents the value from being reversed for
forced-colors, or such. That would allow full per-declaration
granularity, and would prevent the issue Anders is pointing out.

It'd be good to figure out the right thing to override forced-colors
before shipping it IMO. That being said I'm not opposed (quite
supportive, actually) of the rest of the feature. It's just the override
mechanism which I see as potentially problematic.

On 5/1/20 1:06 AM, Anders Hartvoll Ruud wrote:
> Perhaps more actionable feedback:
>  - The spec now mentions that on "user input controls (except
> button-like controls)", background-image should be reverted. We don't do
> this AFAICT.

I don't understand this, and did file [3] about it a while ago.

>  - The background-color should now be forced to different things
> depending on what the computed value of color is. We don't do this either.

Yeah, this is a resolution which seems a bit problematic, adding yet
another property to the "special" bucket (at least if done at
computed-value time). That is also not clear [4], but I'd very much
prefer if we didn't start having chains of dependencies here
(background-color depends on color which depends on
forced-color-adjust), because it makes the implementation substantially
more painful for this very special case.

>  - The spec says "if color is a system color", but the computed value
> of color can't really "be" a system color, can it? The computed value is
> rgb(...), without any "system origin". Spec should clarify.

That is also something that changed in the spec and for which I have a
few other reservations as well. It was resolved that system colors
should indeed be preserved at computed value time[5], but it's not clear
how they are supposed to interpolate, etc... So spec is technically
clear and right here, but of course nobody implements it... yay?

>  - Should forced-colors-mode automatically disable the 'appearance' of
> widgets? (And does the current behavior match what we want)?

That one is an interesting one. I guess this depends on whether "revert"
is supposed to undo the magical "background-color, etc disables native
appearance". In Firefox Nightly it does, so e.g.:

data:text/html,<input style="background-color: revert;"
value="native?">

Looks like a native input element. I think that's sane, but we should
probably discuss it in [6] :)

-- Emilio

[1]: https://github.com/w3c/csswg-drafts/issues/3257
[2]: https://github.com/w3c/csswg-drafts/issues/4178
[3]: https://github.com/w3c/csswg-drafts/issues/4917
[4]: https://github.com/w3c/csswg-drafts/issues/4915
[5]: https://github.com/w3c/csswg-drafts/issues/3847
[6]: https://github.com/w3c/csswg-drafts/issues/4777

> On Thu, Apr 30, 2020 at 10:02 PM 'Alison Maher' via blink-dev
> <blin...@chromium.org <mailto:blin...@chromium.org>> wrote:
>
> *
>
> Contact emails
>
> Rossen.A...@microsoft.com
> <mailto:Rossen.A...@microsoft.com>, Alison...@microsoft.com
> <mailto:Alison...@microsoft.com>
>
>
> Explainer
>
> High Contrast Explainer
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftEdge%2FMSEdgeExplainers%2Fblob%2Fmaster%2FHighContrast%2Fexplainer.md&data=02%7C01%7CRossen.Atanassov%40microsoft.com%7C7e9eda6779584cf1b80008d6865a834d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636844120637921717&sdata=m3DsNo3bPbfBAPFFJ%2F6k129DplQZSx2S%2BRgDms5zdDc%3D&reserved=0>
>
>
> Spec
>
> Forced Colors Mode Spec
> <https://www.w3.org/TR/css-color-adjust-1/#forced>
>
>
> Forced Colors Mode wasn’t considered a candidate for TAG review and
> was directly worked on by the CSS Working Group. This is a user
> facing feature which provides some developer control that has been
> in flight for a decade now. The functionality has been available in
> Internet Explorer and Legacy Microsoft Edge behind
> '-ms-high-contrast' and '-ms-high-contrast-adjust' properties, thus
> making '/forced-colors'/ and '/forced-color-adjust'/ merely aliases
> of the formerly available properties.
>
>
> Summary
>
> Forced Colors Mode is currently only supported on Windows through
> the Windows High Contrast feature. High Contrast was first
> introduced as a Windows accessibility feature
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fdesktop%2Fw8cookbook%2Fhigh-contrast-mode&data=02%7C01%7CRossen.Atanassov%40microsoft.com%7C7e9eda6779584cf1b80008d6865a834d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636844120637941734&sdata=K6TKdah596oLLthO6Yiy9gASoa20sZWctDppH2Ihe8g%3D&reserved=0>for
> individuals who need visual help due to vision problems or poor
> light environments. The goal is to increase text readability for
> such individuals by guaranteeing high color contrast (>10:1) between
> the text and background, while at the same time reducing cognitive
> overload through a simplified color palette.
>
> Applications such as the browser can make use of such color themes
> by propagating them into their web content model. In such
> implementations, the High Contrast colors are propagated to the
> website content as a set of user agent style overrides, thus
> increasing the readability of the web content with guaranteed text
> to background contrast ratios.
>
>
> Link to “Intent to Prototype” blink-dev discussion
>
> Intent to Implement
> <https://groups.google.com/a/chromium.org/forum/?fromgroups#!searchin/blink-dev/intent$20to$20implement$20forced$20colors%7Csort:date/blink-dev/N77UCHle_rw/_CevwXr9BAAJ>
>
>
> Is this feature supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> Yes, Forced Colors Mode is supported on all Blink platforms. For
> now, though, it is only activatable on Windows through a user-chosen
> High Contrast Theme.
>
>
> Demo link
>
> This feature would apply Forced Colors Mode styles to every web page
> and can be demonstrated by toggling the Windows High Contrast
> presentation condition (Windows Start > Settings > Ease of Access >
> High contrast > Turn on High Contrast).
>
>
> Debuggability
>
> Forced Colors Mode styles and properties can be debugged in
> DevTools. DevTools UI support for Forced Colors Mode is underway and
> can be tracked here
> <https://bugs.chromium.org/p/chromium/issues/detail?id=1048378>.
>
>
> A proposed addition to DevTools support is a Forced Colors Mode
> emulation feature. When toggled, this would allow developers to
> debug their page in a simulated High Contrast environment on
> non-Windows devices. This, however, is a future proposal.
>
>
> Risks
>
> Interoperability and Compatibility
>
> High Contrast theming is currently only available on the Windows
> platform. Internet Explorer and Legacy Microsoft Edge supported this
> behind vendor prefixed properties. The popularity of this feature
> has attracted top sites such as Facebook, YouTube, Microsoft Office,
> etc. to take dependencies on the vendor prefixed behavior.
>
>
> These vendor prefixed properties, while still supported in Microsoft
> Edge for backwards compatibility, are not supported in the current
> Chromium implementation. We plan to deprecate the legacy prefixes as
> soon as the standard Forced Colors Mode feature ships everywhere.
>
>
> Edge: Shipped
>
> Firefox: Shipped - using a browser setting
> <https://support.mozilla.org/en-US/kb/accessibility-features-firefox-make-firefox-and-we#w_using-a-high-contrast-theme>(missing
> CSS property and MQ support)
>
> Safari: No signals
>
> Web / Framework developers: Positive
>
>
> Ergonomics
>
> If Forced Colors Mode is enabled at the same time as another color
> scheme, Forced Colors Mode will override the effects of those color
> schemes.
>
>
> For example, if a user has enabled Dark Mode and then sets their
> Windows High Contrast Theme to black-on-white,
> ‘prefers-color-scheme’ will evaluate to match the closest Windows
> High Contrast colors (lightin this example), rather than continuing
> to match the original Dark Mode Theme (dark).
>
>
> Activation
>
> The main feedback received from developers is that it is difficult
> to adjust Forced Colors Mode styles for individual elements rather
> than for an entire subtree of elements. This is currently being
> discussed by the CSSWG
> <https://github.com/w3c/csswg-drafts/issues/4178>.
>
>
> Is this feature fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
> Link to test suite results from wpt.fyi <https://wpt.fyi>.
>
> Yes, this feature is tested by web-platform tests.
>
> *
>
> Web tests
> <https://wpt.fyi/results/css/css-forced-color-adjust?label=master&label=experimental&aligned&q=forced-color-adjust>for
> the ‘forced-color-adjust’ property.
>
> *
>
> Web tests
> <https://wpt.fyi/results/css/mediaqueries?label=master&label=experimental&aligned&q=forced-colors.html>for
> the ‘forced-colors’ media query.
>
> *
>
> Web tests
> <https://wpt.fyi/results/forced-colors-mode?label=master&label=experimental&aligned&q=forced-colors-mode>for
> the Forced Colors Mode feature. These appear as failing because
> they must be run inside of a virtual test suite that simulates
> High Contrast to pass.
>
>
> Entry on the feature dashboard <http://www.chromestatus.com/>
>
> https://www.chromestatus.com/feature/5757293075365888
> <https://www.chromestatus.com/feature/5757293075365888>
>
> *
>
> --
> 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>.
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SN6PR00MB0416DEC17DB005015918F19F8AAA0%40SN6PR00MB0416.namprd00.prod.outlook.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+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUriy94T_O1cUgC-AfCnE-mG4988eCjPjwfovRxsVYi7oA%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUriy94T_O1cUgC-AfCnE-mG4988eCjPjwfovRxsVYi7oA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

alm...@microsoft.com

unread,
May 6, 2020, 2:55:28 PM5/6/20
to blink-dev, and...@chromium.org, Alison...@microsoft.com, Rossen.A...@microsoft.com

Hi Anders and Emilio,


Thank you both for the review and feedback.


Regarding the feedback provided by Anders:


 - The spec has diverged from the Blink implementation. (The Blink implementation was more or less accurate at some point, but not anymore). Most notably the spec now says to revert in the author origin, which means reverting back to the user level. We're currently reverting back to the UA level. (Easy to fix).

That is a good point; I am currently working on a fix for this and will add you for review.


 - The spec now mentions that on "user input controls (except button-like controls)", background-image should be reverted. We don't do this AFAICT.

Windows High Contrast Theme allows users to set different colors for button controls, hence the exception for buttons.


However, I believe this was a remnant of Legacy Microsoft Edge behavior. This shouldn't be needed due to the backplate and could likely be removed from the spec.


 - The background-color should now be forced to different things depending on what the computed value of color is. We don't do this either.

We are currently preserving the alpha channel, as it mentions. The spec is a bit confusing here, though. Was there a specific point in that section that seems to be missing from the current implementation?


 - The spec says "if color is a system color", but the computed value of color can't really "be" a system color, can it? The computed value is rgb(...), without any "system origin". Spec should clarify.

Agreed, this section of the spec is confusing. Based on Emilio's comment, it appears that this is technically correct based on recent spec changes (even though nobody is currently implementing this).


 - Should forced-colors-mode automatically disable the 'appearance' of widgets? (And does the current behavior match what we want)?

Could you clarify what you mean by ‘appearance’ here (the legacy webkit property?) and ‘widgets’ (built-in controls, component model, custom elements etc.?).


We favor consistency over smart exceptions. In other words, the behavior of forcing colors should consistently apply to any and all elements of the document regardless if they are part of the light or shadow DOM. This is the case for built-in controls today. We upstreamed control styling that accounts for Forced Colors Mode and provides the expected and consistent behavior.


----------


Regarding Emilio's feedback:


It'd be good to figure out the right thing to override forced-colors before shipping it IMO.

Thanks for the feedback on this. I think there are three options here. Either we 1) wait until this is addressed to ship, 2) ship everything but 'forced-color-adjust' until this is resolved, or 3) ship everything, and adjust the feature once a solution is confirmed.


It is important to note that shipping a version of Forced Colors Mode without providing developers a way to alter the behavior is going to be very disruptive and not something we’re willing to do. One idea could be to add a new separate property that allows the override of a single element, in addition to the existing one which cascades. In other words, we could ship a new property, ‘force-color-override’, soon after this feature ships, which would provide finer grained control for developers. And ‘forced-color-adjust’ would continue to be good for those who want full control on a sub-tree level, such as component etc.

PhistucK

unread,
May 6, 2020, 5:19:15 PM5/6/20
to alm...@microsoft.com, blink-dev, Anders Hartvoll Ruud, Alison...@microsoft.com, Rossen Atanassov
I assume you already did your due diligence by checking that websites were actually using the feature, but I want to mention that those media queries (-ms-high-contrast for sure) were also used as a hack for writing CSS that was only meant for Internet Explorer (and maybe Edge).
I know this will not make those CSS rules apply in Chrome (because it is not implemented with the -ms- prefix), but does reduce the significance of existing usage counts (and so of the demand).

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/2a3c0608-0b45-47d4-8de7-a6e24656dc3a%40chromium.org.

Chris Harrelson

unread,
May 7, 2020, 2:58:03 PM5/7/20
to alm...@microsoft.com, blink-dev, Anders Hartvoll Ruud, Alison Maher, Rossen Atanassov
This sounds like a topic that should be brought back to the CSSWG for discussion and resolution. Has an issue been filed yet there?

Second point: Emilio also asked if there is evidence the current forced-color-adjust property is needed. You said "It is important to note that shipping a version of Forced Colors Mode without providing developers a way to alter the behavior is going to be very disruptive and not something we’re willing to do". Could you expand on why it would be disruptive? Do you have examples of sites that use it to good effect?

--
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/2a3c0608-0b45-47d4-8de7-a6e24656dc3a%40chromium.org.

Anders Hartvoll Ruud

unread,
May 7, 2020, 3:09:44 PM5/7/20
to Chris Harrelson, alm...@microsoft.com, blink-dev, Alison Maher, Rossen Atanassov
On Thu, May 7, 2020 at 8:57 PM Chris Harrelson <chri...@chromium.org> wrote:


On Wed, May 6, 2020 at 11:55 AM almaher via blink-dev <blin...@chromium.org> wrote:

Hi Anders and Emilio,


Thank you both for the review and feedback.


Regarding the feedback provided by Anders:


 - The spec has diverged from the Blink implementation. (The Blink implementation was more or less accurate at some point, but not anymore). Most notably the spec now says to revert in the author origin, which means reverting back to the user level. We're currently reverting back to the UA level. (Easy to fix).

That is a good point; I am currently working on a fix for this and will add you for review.


 - The spec now mentions that on "user input controls (except button-like controls)", background-image should be reverted. We don't do this AFAICT.

Windows High Contrast Theme allows users to set different colors for button controls, hence the exception for buttons.


However, I believe this was a remnant of Legacy Microsoft Edge behavior. This shouldn't be needed due to the backplate and could likely be removed from the spec.


 - The background-color should now be forced to different things depending on what the computed value of color is. We don't do this either.

We are currently preserving the alpha channel, as it mentions. The spec is a bit confusing here, though. Was there a specific point in that section that seems to be missing from the current implementation?


 - The spec says "if color is a system color", but the computed value of color can't really "be" a system color, can it? The computed value is rgb(...), without any "system origin". Spec should clarify.

Agreed, this section of the spec is confusing. Based on Emilio's comment, it appears that this is technically correct based on recent spec changes (even though nobody is currently implementing this).


 - Should forced-colors-mode automatically disable the 'appearance' of widgets? (And does the current behavior match what we want)?

Could you clarify what you mean by ‘appearance’ here (the legacy webkit property?) and ‘widgets’ (built-in controls, component model, custom elements etc.?).


We favor consistency over smart exceptions. In other words, the behavior of forcing colors should consistently apply to any and all elements of the document regardless if they are part of the light or shadow DOM. This is the case for built-in controls today. We upstreamed control styling that accounts for Forced Colors Mode and provides the expected and consistent behavior.


----------


Regarding Emilio's feedback:


It'd be good to figure out the right thing to override forced-colors before shipping it IMO.

Thanks for the feedback on this. I think there are three options here. Either we 1) wait until this is addressed to ship, 2) ship everything but 'forced-color-adjust' until this is resolved, or 3) ship everything, and adjust the feature once a solution is confirmed.


It is important to note that shipping a version of Forced Colors Mode without providing developers a way to alter the behavior is going to be very disruptive and not something we’re willing to do. One idea could be to add a new separate property that allows the override of a single element, in addition to the existing one which cascades. In other words, we could ship a new property, ‘force-color-override’, soon after this feature ships, which would provide finer grained control for developers. And ‘forced-color-adjust’ would continue to be good for those who want full control on a sub-tree level, such as component etc.

This sounds like a topic that should be brought back to the CSSWG for discussion and resolution. Has an issue been filed yet there?

If you mean the "forced-color-adjust behaves annoyingly" issue, then there's Issue 4155. There are IMO other issues that need processing by the WG, for example Issue 4915 is annoying. In general it seems premature to classify this spec as stable/shippable in my opinion.

Anders Hartvoll Ruud

unread,
May 7, 2020, 3:50:45 PM5/7/20
to alm...@microsoft.com, blink-dev, Alison Maher, Rossen Atanassov
On Wed, May 6, 2020 at 8:55 PM almaher via blink-dev <blin...@chromium.org> wrote:

Hi Anders and Emilio,


Thank you both for the review and feedback.


Regarding the feedback provided by Anders:


 - The spec has diverged from the Blink implementation. (The Blink implementation was more or less accurate at some point, but not anymore). Most notably the spec now says to revert in the author origin, which means reverting back to the user level. We're currently reverting back to the UA level. (Easy to fix).

That is a good point; I am currently working on a fix for this and will add you for review.


 - The spec now mentions that on "user input controls (except button-like controls)", background-image should be reverted. We don't do this AFAICT.

Windows High Contrast Theme allows users to set different colors for button controls, hence the exception for buttons.


However, I believe this was a remnant of Legacy Microsoft Edge behavior. This shouldn't be needed due to the backplate and could likely be removed from the spec.


My issue was not with the button exception, but that we don't actually revert background-image at all. (Unless it's happening somewhere I don't know about).


 - The background-color should now be forced to different things depending on what the computed value of color is. We don't do this either.

We are currently preserving the alpha channel, as it mentions. The spec is a bit confusing here, though. Was there a specific point in that section that seems to be missing from the current implementation?


Yes, the part about background-color taking into 'color' (for system colors). Of course this is a bit hard to do without first implementing system-colors-compute-to-system-colors, which seems out of scope. So probably disregard this issue.
 
 - The spec says "if color is a system color", but the computed value of color can't really "be" a system color, can it? The computed value is rgb(...), without any "system origin". Spec should clarify.

Agreed, this section of the spec is confusing. Based on Emilio's comment, it appears that this is technically correct based on recent spec changes (even though nobody is currently implementing this).


My mistake, didn't know system colors should compute to themselves now.
 

 - Should forced-colors-mode automatically disable the 'appearance' of widgets? (And does the current behavior match what we want)?

Could you clarify what you mean by ‘appearance’ here (the legacy webkit property?) and ‘widgets’ (built-in controls, component model, custom elements etc.?).


Yeah, sorry for using the term 'widgets'. I'm referring to anything with a (non-none) [-webkit-]appearance. We recently decided how revert should behave w.r.t. appearance, so if the updated implementation uses revert, it should get the correct behavior automatically. background-color doesn't use revert, but its "magical adjustment" probably falls outside the definition of "author-styled background/border", so it shouldn't disable appearance either.
 

We favor consistency over smart exceptions. In other words, the behavior of forcing colors should consistently apply to any and all elements of the document regardless if they are part of the light or shadow DOM. This is the case for built-in controls today. We upstreamed control styling that accounts for Forced Colors Mode and provides the expected and consistent behavior.


----------


Regarding Emilio's feedback:


It'd be good to figure out the right thing to override forced-colors before shipping it IMO.

Thanks for the feedback on this. I think there are three options here. Either we 1) wait until this is addressed to ship, 2) ship everything but 'forced-color-adjust' until this is resolved, or 3) ship everything, and adjust the feature once a solution is confirmed.


It is important to note that shipping a version of Forced Colors Mode without providing developers a way to alter the behavior is going to be very disruptive and not something we’re willing to do. One idea could be to add a new separate property that allows the override of a single element, in addition to the existing one which cascades. In other words, we could ship a new property, ‘force-color-override’, soon after this feature ships, which would provide finer grained control for developers. And ‘forced-color-adjust’ would continue to be good for those who want full control on a sub-tree level, such as component etc.

--
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/2a3c0608-0b45-47d4-8de7-a6e24656dc3a%40chromium.org.

alm...@microsoft.com

unread,
May 12, 2020, 12:46:23 PM5/12/20
to blink-dev, chri...@chromium.org, alm...@microsoft.com, Alison...@microsoft.com, Rossen.A...@microsoft.com
I believe the issue was likely around providing finer-grained adjustments for Forced Colors Mode. This issue is currently being discussed by the CSSWG and is linked in the "Activation" section of the i2s: Issue 4178.
 
Second point: Emilio also asked if there is evidence the current forced-color-adjust property is needed. You said "It is important to note that shipping a version of Forced Colors Mode without providing developers a way to alter the behavior is going to be very disruptive and not something we’re willing to do". Could you expand on why it would be disruptive? Do you have examples of sites that use it to good effect?

 

Since ‘forced-color-adjust’ itself is fairly new, there likely aren’t many examples of sites depending on this. But there are sites that use the equivalent ‘-ms’ prefixed adjust property to good effect. For example, Bing Maps uses the adjust property to supply their own High Contrast colors for the entire map. There are also libraries that take a dependency on the adjust property to provide an improved High Contrast experience. One such example is Fluent UI, which is utilized by sites such as Outlook, OneDrive, Teams, etc. Although these examples depend on the ‘-ms-’ prefixed properties, we plan on deprecating those, so providing a solution of Forced Colors Mode without a way to adjust the related styles would be problematic and would break sites such as these.


Beyond external sites, we are currently using 'forced-color-adjust' at the UA level to prevent SVG elements from breaking in Forced Colors Mode (see the last part of the spec for 'forced-color-adjust'). Certain built-in controls are also using this to adjust their styles in Forced Colors Mode. As such, shipping the feature without 'forced-color-adjust' would break the expected behavior for SVG elements and for our built-in controls.

 

--
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 blin...@chromium.org.

alm...@microsoft.com

unread,
May 12, 2020, 12:51:50 PM5/12/20
to blink-dev, alm...@microsoft.com, Alison...@microsoft.com, Rossen.A...@microsoft.com


On Thursday, May 7, 2020 at 12:50:45 PM UTC-7, Anders Hartvoll Ruud wrote:


On Wed, May 6, 2020 at 8:55 PM almaher via blink-dev <blin...@chromium.org> wrote:

Hi Anders and Emilio,


Thank you both for the review and feedback.


Regarding the feedback provided by Anders:


 - The spec has diverged from the Blink implementation. (The Blink implementation was more or less accurate at some point, but not anymore). Most notably the spec now says to revert in the author origin, which means reverting back to the user level. We're currently reverting back to the UA level. (Easy to fix).

That is a good point; I am currently working on a fix for this and will add you for review.


 - The spec now mentions that on "user input controls (except button-like controls)", background-image should be reverted. We don't do this AFAICT.

Windows High Contrast Theme allows users to set different colors for button controls, hence the exception for buttons.


However, I believe this was a remnant of Legacy Microsoft Edge behavior. This shouldn't be needed due to the backplate and could likely be removed from the spec.


My issue was not with the button exception, but that we don't actually revert background-image at all. (Unless it's happening somewhere I don't know about).

No, we aren't currently reverting background-image anywhere. This point in the spec is likely a remnant of Legacy Microsoft Edge behavior. With the backplate feature, this shouldn't be needed and could likely be removed from the spec.
 


 - The background-color should now be forced to different things depending on what the computed value of color is. We don't do this either.

We are currently preserving the alpha channel, as it mentions. The spec is a bit confusing here, though. Was there a specific point in that section that seems to be missing from the current implementation?


Yes, the part about background-color taking into 'color' (for system colors). Of course this is a bit hard to do without first implementing system-colors-compute-to-system-colors, which seems out of scope. So probably disregard this issue.
 
 - The spec says "if color is a system color", but the computed value of color can't really "be" a system color, can it? The computed value is rgb(...), without any "system origin". Spec should clarify.

Agreed, this section of the spec is confusing. Based on Emilio's comment, it appears that this is technically correct based on recent spec changes (even though nobody is currently implementing this).


My mistake, didn't know system colors should compute to themselves now.
 

 - Should forced-colors-mode automatically disable the 'appearance' of widgets? (And does the current behavior match what we want)?

Could you clarify what you mean by ‘appearance’ here (the legacy webkit property?) and ‘widgets’ (built-in controls, component model, custom elements etc.?).


Yeah, sorry for using the term 'widgets'. I'm referring to anything with a (non-none) [-webkit-]appearance. We recently decided how revert should behave w.r.t. appearance, so if the updated implementation uses revert, it should get the correct behavior automatically. background-color doesn't use revert, but its "magical adjustment" probably falls outside the definition of "author-styled background/border", so it shouldn't disable appearance either.
 

We favor consistency over smart exceptions. In other words, the behavior of forcing colors should consistently apply to any and all elements of the document regardless if they are part of the light or shadow DOM. This is the case for built-in controls today. We upstreamed control styling that accounts for Forced Colors Mode and provides the expected and consistent behavior.


----------


Regarding Emilio's feedback:


It'd be good to figure out the right thing to override forced-colors before shipping it IMO.

Thanks for the feedback on this. I think there are three options here. Either we 1) wait until this is addressed to ship, 2) ship everything but 'forced-color-adjust' until this is resolved, or 3) ship everything, and adjust the feature once a solution is confirmed.


It is important to note that shipping a version of Forced Colors Mode without providing developers a way to alter the behavior is going to be very disruptive and not something we’re willing to do. One idea could be to add a new separate property that allows the override of a single element, in addition to the existing one which cascades. In other words, we could ship a new property, ‘force-color-override’, soon after this feature ships, which would provide finer grained control for developers. And ‘forced-color-adjust’ would continue to be good for those who want full control on a sub-tree level, such as component etc.

--
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 blin...@chromium.org.

Chris Harrelson

unread,
May 12, 2020, 1:55:07 PM5/12/20
to alm...@microsoft.com, blink-dev, Alison Maher, Rossen Atanassov
Hi Alison, thanks for these updates.

Would it be possible to get a resolution on the issues Anders mentioned issues before shipping? (e.g. 4155, 4915, but possibly some others too?)

On Tue, May 12, 2020 at 9:51 AM almaher via blink-dev <blin...@chromium.org> wrote:


On Thursday, May 7, 2020 at 12:50:45 PM UTC-7, Anders Hartvoll Ruud wrote:


On Wed, May 6, 2020 at 8:55 PM almaher via blink-dev <blin...@chromium.org> wrote:

Hi Anders and Emilio,


Thank you both for the review and feedback.


Regarding the feedback provided by Anders:


 - The spec has diverged from the Blink implementation. (The Blink implementation was more or less accurate at some point, but not anymore). Most notably the spec now says to revert in the author origin, which means reverting back to the user level. We're currently reverting back to the UA level. (Easy to fix).

That is a good point; I am currently working on a fix for this and will add you for review.


 - The spec now mentions that on "user input controls (except button-like controls)", background-image should be reverted. We don't do this AFAICT.

Windows High Contrast Theme allows users to set different colors for button controls, hence the exception for buttons.


However, I believe this was a remnant of Legacy Microsoft Edge behavior. This shouldn't be needed due to the backplate and could likely be removed from the spec.


My issue was not with the button exception, but that we don't actually revert background-image at all. (Unless it's happening somewhere I don't know about).

No, we aren't currently reverting background-image anywhere. This point in the spec is likely a remnant of Legacy Microsoft Edge behavior. With the backplate feature, this shouldn't be needed and could likely be removed from the spec.

Can this be done now then before shipping?
 
 


 - The background-color should now be forced to different things depending on what the computed value of color is. We don't do this either.

We are currently preserving the alpha channel, as it mentions. The spec is a bit confusing here, though. Was there a specific point in that section that seems to be missing from the current implementation?


Yes, the part about background-color taking into 'color' (for system colors). Of course this is a bit hard to do without first implementing system-colors-compute-to-system-colors, which seems out of scope. So probably disregard this issue.
 
 - The spec says "if color is a system color", but the computed value of color can't really "be" a system color, can it? The computed value is rgb(...), without any "system origin". Spec should clarify.

Agreed, this section of the spec is confusing. Based on Emilio's comment, it appears that this is technically correct based on recent spec changes (even though nobody is currently implementing this).


My mistake, didn't know system colors should compute to themselves now.
 

 - Should forced-colors-mode automatically disable the 'appearance' of widgets? (And does the current behavior match what we want)?

Could you clarify what you mean by ‘appearance’ here (the legacy webkit property?) and ‘widgets’ (built-in controls, component model, custom elements etc.?).


Yeah, sorry for using the term 'widgets'. I'm referring to anything with a (non-none) [-webkit-]appearance. We recently decided how revert should behave w.r.t. appearance, so if the updated implementation uses revert, it should get the correct behavior automatically. background-color doesn't use revert, but its "magical adjustment" probably falls outside the definition of "author-styled background/border", so it shouldn't disable appearance either.
 

We favor consistency over smart exceptions. In other words, the behavior of forcing colors should consistently apply to any and all elements of the document regardless if they are part of the light or shadow DOM. This is the case for built-in controls today. We upstreamed control styling that accounts for Forced Colors Mode and provides the expected and consistent behavior.


----------


Regarding Emilio's feedback:


It'd be good to figure out the right thing to override forced-colors before shipping it IMO.

Thanks for the feedback on this. I think there are three options here. Either we 1) wait until this is addressed to ship, 2) ship everything but 'forced-color-adjust' until this is resolved, or 3) ship everything, and adjust the feature once a solution is confirmed.


It is important to note that shipping a version of Forced Colors Mode without providing developers a way to alter the behavior is going to be very disruptive and not something we’re willing to do. One idea could be to add a new separate property that allows the override of a single element, in addition to the existing one which cascades. In other words, we could ship a new property, ‘force-color-override’, soon after this feature ships, which would provide finer grained control for developers. And ‘forced-color-adjust’ would continue to be good for those who want full control on a sub-tree level, such as component etc.

--
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 blin...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2a3c0608-0b45-47d4-8de7-a6e24656dc3a%40chromium.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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1c8b76e3-839a-4b28-98fe-67b092481013%40chromium.org.

alm...@microsoft.com

unread,
May 12, 2020, 2:16:42 PM5/12/20
to blink-dev, alm...@microsoft.com, Alison...@microsoft.com, Rossen.A...@microsoft.com


On Tuesday, May 12, 2020 at 10:55:07 AM UTC-7, Chris Harrelson wrote:
Hi Alison, thanks for these updates.

Would it be possible to get a resolution on the issues Anders mentioned issues before shipping? (e.g. 4155, 4915, but possibly some others too?)

That sounds like a reasonable plan to me. We will try and get these issues discussed with the CSSWG as soon as we can.


On Tue, May 12, 2020 at 9:51 AM almaher via blink-dev <blin...@chromium.org> wrote:


On Thursday, May 7, 2020 at 12:50:45 PM UTC-7, Anders Hartvoll Ruud wrote:


On Wed, May 6, 2020 at 8:55 PM almaher via blink-dev <blin...@chromium.org> wrote:

Hi Anders and Emilio,


Thank you both for the review and feedback.


Regarding the feedback provided by Anders:


 - The spec has diverged from the Blink implementation. (The Blink implementation was more or less accurate at some point, but not anymore). Most notably the spec now says to revert in the author origin, which means reverting back to the user level. We're currently reverting back to the UA level. (Easy to fix).

That is a good point; I am currently working on a fix for this and will add you for review.


 - The spec now mentions that on "user input controls (except button-like controls)", background-image should be reverted. We don't do this AFAICT.

Windows High Contrast Theme allows users to set different colors for button controls, hence the exception for buttons.


However, I believe this was a remnant of Legacy Microsoft Edge behavior. This shouldn't be needed due to the backplate and could likely be removed from the spec.


My issue was not with the button exception, but that we don't actually revert background-image at all. (Unless it's happening somewhere I don't know about).

No, we aren't currently reverting background-image anywhere. This point in the spec is likely a remnant of Legacy Microsoft Edge behavior. With the backplate feature, this shouldn't be needed and could likely be removed from the spec.

Can this be done now then before shipping?

Yeah, we'll work on getting this resolved, along with the other issues mentioned.

 
 


 - The background-color should now be forced to different things depending on what the computed value of color is. We don't do this either.

We are currently preserving the alpha channel, as it mentions. The spec is a bit confusing here, though. Was there a specific point in that section that seems to be missing from the current implementation?


Yes, the part about background-color taking into 'color' (for system colors). Of course this is a bit hard to do without first implementing system-colors-compute-to-system-colors, which seems out of scope. So probably disregard this issue.
 
 - The spec says "if color is a system color", but the computed value of color can't really "be" a system color, can it? The computed value is rgb(...), without any "system origin". Spec should clarify.

Agreed, this section of the spec is confusing. Based on Emilio's comment, it appears that this is technically correct based on recent spec changes (even though nobody is currently implementing this).


My mistake, didn't know system colors should compute to themselves now.
 

 - Should forced-colors-mode automatically disable the 'appearance' of widgets? (And does the current behavior match what we want)?

Could you clarify what you mean by ‘appearance’ here (the legacy webkit property?) and ‘widgets’ (built-in controls, component model, custom elements etc.?).


Yeah, sorry for using the term 'widgets'. I'm referring to anything with a (non-none) [-webkit-]appearance. We recently decided how revert should behave w.r.t. appearance, so if the updated implementation uses revert, it should get the correct behavior automatically. background-color doesn't use revert, but its "magical adjustment" probably falls outside the definition of "author-styled background/border", so it shouldn't disable appearance either.
 

We favor consistency over smart exceptions. In other words, the behavior of forcing colors should consistently apply to any and all elements of the document regardless if they are part of the light or shadow DOM. This is the case for built-in controls today. We upstreamed control styling that accounts for Forced Colors Mode and provides the expected and consistent behavior.


----------


Regarding Emilio's feedback:


It'd be good to figure out the right thing to override forced-colors before shipping it IMO.

Thanks for the feedback on this. I think there are three options here. Either we 1) wait until this is addressed to ship, 2) ship everything but 'forced-color-adjust' until this is resolved, or 3) ship everything, and adjust the feature once a solution is confirmed.


It is important to note that shipping a version of Forced Colors Mode without providing developers a way to alter the behavior is going to be very disruptive and not something we’re willing to do. One idea could be to add a new separate property that allows the override of a single element, in addition to the existing one which cascades. In other words, we could ship a new property, ‘force-color-override’, soon after this feature ships, which would provide finer grained control for developers. And ‘forced-color-adjust’ would continue to be good for those who want full control on a sub-tree level, such as component etc.

--
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 blin...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2a3c0608-0b45-47d4-8de7-a6e24656dc3a%40chromium.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 blin...@chromium.org.

Emilio Cobos Álvarez

unread,
May 12, 2020, 2:42:12 PM5/12/20
to alm...@microsoft.com, blink-dev, chri...@chromium.org, Alison...@microsoft.com, Rossen.A...@microsoft.com

Seems like that could be fixed without shipping the property to content though, right?

--
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 blin...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2a3c0608-0b45-47d4-8de7-a6e24656dc3a%40chromium.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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7ba1befa-9cfa-4c89-a85a-81f6fa20b5b9%40chromium.org.

Rune Lillesveen

unread,
May 13, 2020, 2:12:18 PM5/13/20
to Emilio Cobos Álvarez, alm...@microsoft.com, blink-dev, Chris Harrelson, Alison Maher, Rossen.A...@microsoft.com
On Tue, May 12, 2020 at 8:42 PM Emilio Cobos Álvarez <emi...@crisal.io> wrote:
On 5/12/20 6:46 PM, almaher via blink-dev wrote:

Since ‘forced-color-adjust’ itself is fairly new, there likely aren’t many examples of sites depending on this. But there are sites that use the equivalent ‘-ms’ prefixed adjust property to good effect. For example, Bing Maps uses the adjust property to supply their own High Contrast colors for the entire map. There are also libraries that take a dependency on the adjust property to provide an improved High Contrast experience. One such example is Fluent UI, which is utilized by sites such as Outlook, OneDrive, Teams, etc. Although these examples depend on the ‘-ms-’ prefixed properties, we plan on deprecating those, so providing a solution of Forced Colors Mode without a way to adjust the related styles would be problematic and would break sites such as these.


Beyond external sites, we are currently using 'forced-color-adjust' at the UA level to prevent SVG elements from breaking in Forced Colors Mode (see the last part of the spec for 'forced-color-adjust'). Certain built-in controls are also using this to adjust their styles in Forced Colors Mode. As such, shipping the feature without 'forced-color-adjust' would break the expected behavior for SVG elements and for our built-in controls.

Seems like that could be fixed without shipping the property to content though, right?

Yes. Making the feature available to UA sheets only is straightforward. Do we use forced-color-adjust:none for WebUI/internal pages as well?

alm...@microsoft.com

unread,
May 15, 2020, 2:28:41 PM5/15/20
to blink-dev, emi...@crisal.io, alm...@microsoft.com, chri...@chromium.org, Alison...@microsoft.com, Rossen.A...@microsoft.com, fut...@chromium.org
Agreed, this should be easy enough for UA sheets. However, from what I can tell, there are built-in control styles using 'forced-color-adjust:none' that are set outside the UA level.

We do use 'forced-color-adjust:none' for WebUI in Microsoft Edge, although I'm not sure if upstream Chromium does so, as well.

Anders Hartvoll Ruud

unread,
Aug 19, 2020, 2:27:03 PM8/19/20
to alm...@microsoft.com, blink-dev, emi...@crisal.io, Chris Harrelson, Alison Maher, Rossen Atanassov, Rune Lillesveen
What's the status of this now?

There has been progress/resolutions on some of the spec issues at least? The Blink implementation has been updated (by almaher) to revert in the correct origin, and we found a good (enough) solution to the awkward "force rgb values but not alpha" behavior via the -internal-forced-background-color-rgb property. So at least the Blink implementation is in fairly good shape now.

Are there still any outstanding spec issues (that are important enough to block shipping)? (Alison? Emilio?)

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

Chris Harrelson

unread,
Aug 19, 2020, 2:32:51 PM8/19/20
to Anders Hartvoll Ruud, alm...@microsoft.com, blink-dev, Emilio Cobos Álvarez, Alison Maher, Rossen Atanassov, Rune Lillesveen
One of the issues that I believe was raised in this thread was discussed today at the CSSWG (and maybe resolved enough to be finished). So there is progress being made. Alison, do you think everything is resolved now?

Alison Maher

unread,
Aug 19, 2020, 3:30:29 PM8/19/20
to blink-dev, Chris Harrelson, alm...@microsoft.com, blink-dev, Emilio Cobos Álvarez, Alison Maher, Rossen Atanassov, Rune Lillesveen, and...@chromium.org, dli...@microsoft.com
As Chris mentioned, this issue was the last open issue raised in the thread. That issue was resolved by the CSSWG this morning, but I will want to see how the spec is updated based on the resolution in order to make the necessary code adjustments. The reason being that it sounded like we may want to remove the wording in the spec around Forced Colors being implemented through a simple revert, which would require a change to how Forced Colors Mode is handled in the cascade.

Once I have addressed that issue, we should be in good shape to ship the feature. The only other remaining work that I am aware of is around prefers-contrast. This media query is not implemented in Blink, but it was recently decided upon to add forced as a keyword that would match in Forced Colors Mode. I don’t think prefers-contrast should block shipping since it could be shipped separately. If others feel that this would be blocking, there is an open CSSWG issue related to prefers-contrast that I would want to see resolved before implementing.

Anders Hartvoll Ruud

unread,
Aug 20, 2020, 5:41:04 AM8/20/20
to Alison Maher, blink-dev, Chris Harrelson, Emilio Cobos Álvarez, Alison Maher, Rossen Atanassov, Rune Lillesveen, dli...@microsoft.com
I see, thank you for the update. The spec edit has been made now, looks like the new thinking is that forced colors mode now is a plain "adjustment" on the computed values, and doesn't really interact with the cascade anymore. (Maybe we could implement it entirely in StyleAdjuster if we base it on the CSSSystemColorComputeToSelf feature? Anyway, we can discuss that elsewhere ...)

Alison Maher

unread,
Dec 3, 2020, 5:54:09 PM12/3/20
to blink-dev, and...@chromium.org, blink-dev, Chris Harrelson, Emilio Cobos Álvarez, Alison Maher, Rossen Atanassov, Rune Lillesveen, dli...@microsoft.com, Alison Maher, dmaz...@chromium.org
As an update, the implementation of all of the latest Forced Colors Mode spec changes have landed, so we should be in a good state to ship (unless there are any other outstanding issues or concerns from others).

If approved to ship, we will be coordinating the launch process with the accessibility team (launch bug: crbug.com/1148418).
(+dmazzoni@ for visibility)

Alison Maher

unread,
Dec 9, 2020, 7:24:04 PM12/9/20
to blink-dev, Alison Maher, and...@chromium.org, blink-dev, Chris Harrelson, Emilio Cobos Álvarez, Alison Maher, Rossen Atanassov, Rune Lillesveen, dli...@microsoft.com, Dominic Mazzoni
Pinging this thread. We'd like to ship this in M89 - given that the feedback has been addressed via spec and implementation updates, any other thoughts or concerns from API OWNERS?

Chris Harrelson

unread,
Dec 9, 2020, 7:30:06 PM12/9/20
to Alison Maher, blink-dev, and...@chromium.org, Emilio Cobos Álvarez, Alison Maher, Rossen Atanassov, Rune Lillesveen, dli...@microsoft.com, Dominic Mazzoni

Chris Harrelson

unread,
Dec 9, 2020, 7:33:48 PM12/9/20
to Alison Maher, blink-dev, and...@chromium.org, Emilio Cobos Álvarez, Alison Maher, Rossen Atanassov, Rune Lillesveen, dli...@microsoft.com, Dominic Mazzoni
Actually: it appears this feature should really have a TAG review, especially since it has significant accessibility and platform complexity. (I don't think Chromium-based Edge shipping an earlier iteration should count.)

Please do file the TAG review. There is still more than a month before the M89 branch point, so there will be at least some time for any review concerns.

Please also file signals via bit.ly/blink-signals. For Gecko in particular, the review will be for the MQ and CSS aspects.

Dominic Mazzoni

unread,
Dec 10, 2020, 3:05:06 PM12/10/20
to Chris Harrelson, Alison Maher, blink-dev, and...@chromium.org, Emilio Cobos Álvarez, Alison Maher, Rossen Atanassov, Rune Lillesveen, dli...@microsoft.com
I'd like to enable the kForcedColors feature on trunk this week if there are no objections. This is going to affect the way websites look for users who have high-contrast mode enabled on Windows, and since we're still hoping to ship in M89, I'd rather enable it sooner rather than later so there are more chances to get feedback from developers and early adopters on dev & canary. Of course we'll revert that change if any blocking issues are found in the TAG review or with the I2S.

Please let me know if you have any concerns about this plan. Thanks.

Chris Harrelson

unread,
Dec 10, 2020, 4:31:50 PM12/10/20
to Dominic Mazzoni, Alison Maher, blink-dev, and...@chromium.org, Emilio Cobos Álvarez, Alison Maher, Rossen Atanassov, Rune Lillesveen, dli...@microsoft.com
The API owners considered this request today. We think it's ok to turn it on *via Finch* on Canary and Dev in parallel with finalization of the intent-to-ship process.

We also decided that we need to formalize a process around it, but did not conclude the discussion. For now, everyone should just ask if they would like to turn on a new feature for early testing.

Dominic Mazzoni

unread,
Dec 10, 2020, 4:39:16 PM12/10/20
to Chris Harrelson, Alison Maher, blink-dev, and...@chromium.org, Emilio Cobos Álvarez, Alison Maher, Rossen Atanassov, Rune Lillesveen, dli...@microsoft.com
Thanks! I'll send out a change to enable it via Finch. A more formal process around when to enable things sounds good. Please do consider the distinction between launches that only add a new developer-facing API change (I suspect the majority of I2Ss) vs changes like this one that are more user-facing and have an associated browser launch bug, which comes with different rules and processes.

Chris Harrelson

unread,
Dec 10, 2020, 4:43:00 PM12/10/20
to Dominic Mazzoni, Alison Maher, blink-dev, and...@chromium.org, Emilio Cobos Álvarez, Alison Maher, Rossen Atanassov, Rune Lillesveen, dli...@microsoft.com
On Thu, Dec 10, 2020 at 1:39 PM Dominic Mazzoni <dmaz...@chromium.org> wrote:
Thanks! I'll send out a change to enable it via Finch. A more formal process around when to enable things sounds good. Please do consider the distinction between launches that only add a new developer-facing API change (I suspect the majority of I2Ss) vs changes like this one that are more user-facing and have an associated browser launch bug, which comes with different rules and processes.

That's a very good point, thank you for mentioning it.

Rossen Atanassov

unread,
Dec 10, 2020, 4:46:01 PM12/10/20
to chri...@chromium.org, dmazzoni, Alison Maher, blin...@chromium.org, and...@chromium.org, emi...@crisal.io, fut...@chromium.org, Daniel Libby

Wow, this is awesome progress and great to see this capability progress to the next step!

 

+1 to Dominic’s clarification. Considering features such as native UIAutomation API that have deep browser/OS platform integration vs hybrid ones like Color Schemes (enabled through OS, browser app or a combination) and forced colors (enabled through OS) that may or may not have web API exposure.

Alison Maher

unread,
Dec 10, 2020, 5:52:40 PM12/10/20
to blink-dev, Rossen Atanassov, Alison Maher, blin...@chromium.org, and...@chromium.org, emi...@crisal.io, Rune Lillesveen, dli...@microsoft.com, chri...@chromium.org, Dominic Mazzoni
Thank you all for the feedback! It looks like a TAG review was recently opened for the CSS Color Adjust Level 1 spec, which encompasses the Forced Colors Mode feature. However, please let me know if that shouldn't be sufficient, and I can open one separately.

I have also filed signals with Gecko and WebKit in regards to the feature.

Chris Harrelson

unread,
Dec 10, 2020, 5:58:47 PM12/10/20
to Alison Maher, Rossen Atanassov, Alison Maher, blin...@chromium.org, and...@chromium.org, emi...@crisal.io, Rune Lillesveen, dli...@microsoft.com, Dominic Mazzoni
On Thu, Dec 10, 2020 at 2:52 PM 'Alison Maher' via blink-dev <blin...@chromium.org> wrote:
Thank you all for the feedback! It looks like a TAG review was recently opened for the CSS Color Adjust Level 1 spec, which encompasses the Forced Colors Mode feature. However, please let me know if that shouldn't be sufficient, and I can open one separately.

How about commenting on that TAG review saying that you'd appreciate in particular a review of the forced colors mode, which is planned to ship in its full form in the first browser soon?

I have also filed signals with Gecko and WebKit in regards to the feature.

Thanks!
 

Alison Maher

unread,
Dec 10, 2020, 7:02:59 PM12/10/20
to blink-dev, Chris Harrelson, Rossen Atanassov, Alison Maher, blin...@chromium.org, and...@chromium.org, emi...@crisal.io, Rune Lillesveen, dli...@microsoft.com, Dominic Mazzoni, Alison Maher
> How about commenting on that TAG review saying that you'd appreciate in particular a review of the forced colors mode, which is planned to ship in its full form in the first browser soon?  

Good idea - I've added a comment to the TAG review.

Dominic Mazzoni

unread,
Dec 14, 2020, 1:22:44 PM12/14/20
to Chris Harrelson, Alison Maher, blink-dev, and...@chromium.org, Emilio Cobos Álvarez, Alison Maher, Rossen Atanassov, Rune Lillesveen, dli...@microsoft.com
Slight update here. For Finch if we want to enable at 100% we have to also enable on trunk. OK to enable on trunk and also land the Finch experiment so that it's ready as a kill switch?

(The other alternative would be a 50/50 Finch experiment, but that means ~50% of web developers wouldn't be getting this and wouldn't have advance warning of this change potentially coming to stable soon.)

Chris Harrelson

unread,
Dec 14, 2020, 7:35:45 PM12/14/20
to Dominic Mazzoni, Alison Maher, blink-dev, and...@chromium.org, Emilio Cobos Álvarez, Alison Maher, Rossen Atanassov, Rune Lillesveen, dli...@microsoft.com
Hi Dominic,

Are you ok trying a 50/50 Canary/Dev experiment? I think it'd still get the stability and other data you want, while possibly being less confusing to developers in another way.

In a parallel thread, we're discussing what the policy going forward should be for requests like this. For new APIs, I raised a concern that anything more than 50% on canary/dev would get confusing in terms of some people thinking we are soft launching a feature. Trying 50/50 and seeing if it is causing too much confusion for developers or not would also help to answer this question.

A second point is that I don't think it's a great idea to turn it on for trunk before approval, because "downstream" Chromium-based browsers do not necessarily have a Finch equivalent. (Other teams have accidentally made mistakes of this kind before where we forgot about that situation, e.g. in the initial LayoutNG launch.)

Chris
 

Jeffrey Yasskin

unread,
Dec 15, 2020, 10:49:57 AM12/15/20
to Alison Maher, blink-dev, and...@chromium.org, Emilio Cobos Álvarez, Alison Maher, Rossen Atanassov, dli...@microsoft.com, Paul Jensen
There's a bit of concern on the anti-fingerprinting team at Google about how identifiable users become if they enable forced-colors mode. Fantasai recently opened https://github.com/w3c/csswg-drafts/issues/5710 to consider hiding the change from getComputedStyle(), but to know how important that is, we have to know how configurable the colors actually are.

Is forced-colors mode a single switch that users could turn on or off, or does it let users specify a possibly-unique set of colors? In the Mac Display accessibility settings, I see 2 checkboxes and a 5-option dropdown that might get propagated to the page? On Windows, the High contrast control panel seems to allow users to specify an arbitrary color for each of text, hyperlinks, disabled text, selected text, button text, and the background. Would those all be propagated into the result of getComputedStyle()?

Have y'all at Microsoft developed an opinion on whether the color customization should be hidden from the page?

Thanks,
Jeffrey

Dominic Mazzoni

unread,
Dec 15, 2020, 11:52:25 AM12/15/20
to Chris Harrelson, Alison Maher, blink-dev, and...@chromium.org, Emilio Cobos Álvarez, Alison Maher, Rossen Atanassov, Rune Lillesveen, dli...@microsoft.com
On Mon, Dec 14, 2020 at 4:35 PM Chris Harrelson <chri...@chromium.org> wrote:
Hi Dominic,

Are you ok trying a 50/50 Canary/Dev experiment? I think it'd still get the stability and other data you want, while possibly being less confusing to developers in another way.

Sure, happy to start there.

Alison Maher

unread,
Dec 15, 2020, 6:53:22 PM12/15/20
to blink-dev, jyas...@chromium.org, blink-dev, and...@chromium.org, Emilio Cobos Álvarez, Alison Maher, Rossen Atanassov, dli...@microsoft.com, Paul Jensen, Alison Maher

Hi Jeffrey,

Thanks for bringing up the anti-fingerprinting concerns. To answer your main question, yes, forced colors mode can be used to specify a possibly-unique set of colors given that the Windows HC feature can be used to create a unique forced color scheme. And those colors would be propagated into the result of getComputedStyle().

However, there are a few important points here:
  1. The vast majority of Windows HC users use built-in themes, which reduces the severity of fingerprinting risk for most HC users.
  2. The system colors for Windows are already exposed, and the new system color keywords shipped separately from the forced colors mode feature:
    Intent to Ship: Canvas and Text system colors (google.com)
    Intent to Ship: ActiveText, Field, and FieldText system colors (google.com)
    Windows HC updates the system colors, so these colors are already exposed in Chromium through the use of system color keywords (outside of forced colors mode being enabled).
  3. Some of the fingerprinting risks surrounding the use of system colors can be found in the CSS color spec: CSS Color Module Level 4 (w3.org)
Given the above points, the fingerprinting surface exposed by shipping this feature is whether a user has Windows High Contrast mode enabled. Since the system colors are already exposed, adjusting the returned value of system color keywords from getComputedStyle() would likely be separate from the forced colors mode feature.

​Please let me know if I can provide any further details or clarification.

Alison Maher

unread,
Jan 12, 2021, 2:05:50 PMJan 12
to blink-dev, Alison Maher, jyas...@chromium.org, blink-dev, and...@chromium.org, Emilio Cobos Álvarez, Alison Maher, Rossen Atanassov, dli...@microsoft.com, Paul Jensen
As a quick update, TAG review feedback has been provided, and there weren't any issues raised that should block from shipping the Forced Colors feature. And as noted in the TAG review, the launch of this feature includes the 'forced-colors' media query and 'forced-color-adjust' property. We will not be shipping with the 'prefers-contrast' media query initially as there is an open spec issue around its syntax, and the plan is to ship this separately once the outstanding issue has been resolved.

Yoav Weiss

unread,
Jan 13, 2021, 3:17:53 AMJan 13
to Alison Maher, blink-dev, jyas...@chromium.org, and...@chromium.org, Emilio Cobos Álvarez, Alison Maher, Rossen Atanassov, dli...@microsoft.com, Paul Jensen
Is the renaming brought up in the TAG review not a blocker?

Alice Boxhall

unread,
Jan 13, 2021, 3:42:48 AMJan 13
to Yoav Weiss, Alison Maher, blink-dev, jyas...@chromium.org, and...@chromium.org, Emilio Cobos Álvarez, Alison Maher, Rossen Atanassov, dli...@microsoft.com, Paul Jensen
To clarify: the suggestion we made was to fold color-adjust into forced-color-adjust, rather than the converse.

Daniel Libby

unread,
Jan 13, 2021, 4:38:07 PMJan 13
to blink-dev, A Boxhall, Alison Maher, blink-dev, jyas...@chromium.org, and...@chromium.org, Emilio Cobos Álvarez, Alison Maher, Rossen Atanassov, Daniel Libby, Paul Jensen, yo...@yoav.ws
Given the positive reception from TAG review for the APIs under consideration for shipping, I don't think we need to block on the resolution on whether the uses cases for `color-adjust` (which is not part of this i2s) are covered by `forced-color-adjust`.

yoav@- does this address your concerns with the TAG review?

Yoav Weiss

unread,
Jan 14, 2021, 3:28:27 AMJan 14
to Daniel Libby, blink-dev, A Boxhall, Alison Maher, jyas...@chromium.org, and...@chromium.org, Emilio Cobos Álvarez, Alison Maher, Rossen Atanassov, Paul Jensen
LGTM1

On Wed, Jan 13, 2021 at 10:38 PM 'Daniel Libby' via blink-dev <blin...@chromium.org> wrote:
Given the positive reception from TAG review for the APIs under consideration for shipping, I don't think we need to block on the resolution on whether the uses cases for `color-adjust` (which is not part of this i2s) are covered by `forced-color-adjust`. 

yoav@- does this address your concerns with the TAG review?

Yeah, that answers my question.
 

Daniel Bratell

unread,
Jan 14, 2021, 1:50:14 PMJan 14
to Yoav Weiss, Daniel Libby, blink-dev, A Boxhall, Alison Maher, jyas...@chromium.org, and...@chromium.org, Emilio Cobos Álvarez, Alison Maher, Rossen Atanassov, Paul Jensen

Mike West

unread,
Jan 14, 2021, 2:33:44 PMJan 14
to Daniel Bratell, Yoav Weiss, Daniel Libby, blink-dev, A Boxhall, Alison Maher, jyas...@chromium.org, and...@chromium.org, Emilio Cobos Álvarez, Alison Maher, Rossen Atanassov, Paul Jensen
The fingerprinting risk discussed above is already web-exposed, given that system colors already change when the user enables high contrast mode. The media queries this feature exposes do little more than allow developers to react to the user's decision, similarly to their reactions to other user decisions, like dark mode and reduced motion. It does seem reasonable for us to return to the question of whether the system color values ought to be exposed via `getComputedStyle()`, as those seem plausibly more-fingerprintable than it needs to be. That conversation shouldn't, however, block this intent.

LGTM3.

-mike


Im Phoung

unread,
Jan 15, 2021, 11:02:52 AMJan 15
to Mike West, A Boxhall, Alison Maher, Alison Maher, Daniel Bratell, Daniel Libby, Emilio Cobos Álvarez, Paul Jensen, Rossen Atanassov, Yoav Weiss, and...@chromium.org, blink-dev, jyas...@chromium.org
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/hkjRPJ1-Ruk/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAKXHy%3Dcm-3-DrwASNWwK3d%2BNWHSnEqdkZMzhAdSQgVFnBNOiGA%40mail.gmail.com.
--

Reply all
Reply to author
Forward
0 new messages