Intent to Ship: Forced Colors Mode
Alison Maher
Contact emails
Rossen.A...@microsoft.com, Alison...@microsoft.com
Explainer
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
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
Stephen Mcgruer
--
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
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
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
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:
> 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.
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.
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)?
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
>
> *
>
> 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
>
> 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
>
>
> 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
> 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
>
> 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
>
>
> 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 <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
> they must be run inside of a virtual test suite that simulates
> High Contrast to pass.
>
>
>
> 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
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SN6PR00MB0416DEC17DB005015918F19F8AAA0%40SN6PR00MB0416.namprd00.prod.outlook.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
> <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
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
--
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
--
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
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?
Anders Hartvoll Ruud
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.
--
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
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
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).
- 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
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.
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
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?)
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 blin...@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.
Emilio Cobos Álvarez
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
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?
alm...@microsoft.com
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
--
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/48326404-b0e2-4ac3-aa29-5dcd96e8d82b%40chromium.org.
Chris Harrelson
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUpbtMULUW8ZkZKEzb4zMbi1koFhUW-CLi-zveye5Z1tDw%40mail.gmail.com.
Alison Maher
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
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/41e8e6df-f2ac-40d7-a933-a96fc9d21d0cn%40chromium.org.
Alison Maher
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
Chris Harrelson
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fb51b9e0-0594-4b9c-8e1a-3aa1549d6caan%40chromium.org.
Chris Harrelson
Dominic Mazzoni
Chris Harrelson
Dominic Mazzoni
Chris Harrelson
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFz-FYwSEprJ1SV5h0sNRqoKePBV58faxHH0g1ddGxQbTNPjtA%40mail.gmail.com.
Rossen Atanassov
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
I have also filed signals with Gecko and WebKit in regards to the feature.
Chris Harrelson
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9c645a05-337a-4c59-b747-99baf0436d57n%40chromium.org.
Alison Maher
Dominic Mazzoni
Chris Harrelson
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFz-FYwBnNR8uYqD6a7RAF1dhrBBL7sjVBnDCzvTcL9DmyaGnQ%40mail.gmail.com.
Jeffrey Yasskin
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fb51b9e0-0594-4b9c-8e1a-3aa1549d6caan%40chromium.org.
Dominic Mazzoni
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.
Alison Maher
However, there are a few important points here:
- The vast majority of Windows HC users use built-in themes, which reduces the severity of fingerprinting risk for most HC users.
- 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). - 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)
Please let me know if I can provide any further details or clarification.
Alison Maher
Yoav Weiss
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/99d9d515-6c90-46d5-9f8e-ef51a8a52b5fn%40chromium.org.
Alice Boxhall
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgL1TQCzW8FE3kO0k_UoS3x-dtDpFD27wtzjO4isvkkRQ%40mail.gmail.com.
Daniel Libby
Yoav Weiss
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?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2995dd46-17e0-4701-8bee-781597aa5020n%40chromium.org.
Daniel Bratell
LGTM2
/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEiXNq%2B67WLk9KGk1P1%3D19saBmmBSK770%2Bd1E1SH4c888Q%40mail.gmail.com.
Mike West
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2e2bd3a8-335c-a83c-7a44-18b8fc9078f4%40gmail.com.
Im Phoung
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.