Re: [csswg-drafts] [various] Holistic review/proposal of color-modifying things (#3807)

Hooking this thread to provide my own feedback.

Before anything, I wanted to say I generally approve the compromise solution outlined by Tab and Fantasai above:

> ✔ proposed renaming: `forced-colors[-adjust]` vs `high-contrast[-adjust]`
> ✔ proposed interaction with `prefers-color-mode: dark` (though I would add a note that it's preferable to compare the lightness of the forced text color vs the forced background color, and return based on which one is lighter)
> ✔ proposed no direct interaction with `prefers-contrast` (though UAs supporting `forced-colors` could auto-detect user preference for high contrast based on the contrast ratio between the forced text color vs the forced background color; if those are high-contrast and forced-colors is enabled, then `prefers-contrast` should also be enabled)

Now, back on to the MS proposal. My main concern is with the Cascade Order section:

> Given an element and a declaration from a CSS rule whose selector matches that element, the application of that declaration will be suppressed if all of the following conditions are met:
> 1. The declaration is for a CSS property in the set of properties that are adjusted for high contrast (as defined in CSS Properties)
> 2. High contrast mode is enabled in the host environment
> 3. The computed value of high-contrast-adjust on the element is auto
> 4. The rule is not contained (directly or indirectly) inside an @media block matching the high-contrast media feature
> 5. The rule is not defined in the default UA style sheet
> 
> If all of the above conditions are met, the computed color value of the CSS property is overridden by a system color value.

It's way too complex. I understand that this is how things used to work in IE, but I don't think we want to import this complexity in modern browsers.

**First point:** My understanding is that if you want to use your own colors in Edge, you should always set `forced-colors-adjust: none` otherwise the backplate will be drawn with the forced background which is unpredictable. Therefore, I think we should remove condition `2.` and only consider whether `forced-colors-adjust` is set to `none` or not. Compatibility with `-ms-` prefixed content can be achieved by automatically setting `forced-colors-adjust` to `none` when a declaration for a `color` property is detected in an `@media(-ms-high-contrast)` rule, which can be done at parse time instead of having to be done every time things get computed.

**Second point:** Disabling declarations based on the computed value of a property is against the normal flow of property computation, and would require a special computation pass just for `forced-colors-adjust`, and that is cumbersome. 

Based on these two points, I propose an alternative solution: drop the entire cascade section, and replace it with the following text: 

> after cascade as been applied (and if the `forced-colors` mode is active), elements which have their `forced-colors-adjust` property set to `auto` have the specified value of all its properties on which `forced-colors` apply set to `revert` (this effectively inhibits any author-provided value, and revert to the default ua stylesheet).

Gecko and Servo already support the `revert` value, and so does Webkit. I therefore guess it wouldn't be very complex for Blink to do as well. This would be way simpler to implement than the proposed cascade behavior for almost the same result (except the minor change I introduced in my first point).

**Apart from those two points about the cascade order,** I would like to point out again that I am in favor of the general proposal.



-- 
GitHub Notification of comment by FremyCompany
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3807#issuecomment-481845423 using your GitHub account

Received on Wednesday, 10 April 2019 20:16:31 UTC