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
--
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.
--
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.
--
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.
--
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.
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?
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.
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.
--
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.
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.
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.
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.
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.
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?
--
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.
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.
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.
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.
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.
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.
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFz-FYwBnNR8uYqD6a7RAF1dhrBBL7sjVBnDCzvTcL9DmyaGnQ%40mail.gmail.com.
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.
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.
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.
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.
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.
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.
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.
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.