Re: [csswg-drafts] [css-color-adjust-1] more granular overriding of forced colors mode than per-element (#4178)

Not sure if this will come up in today's discussion on custom origins, but in case it does, here are my thoughts on this.

## Background
Forced colors mode mostly does two things:
- Remap colors to valid known defaults (appropriate system colors)
- Ensure text readability when drawn over unknown backgrounds

I am only aware of two ways one would want to adjust the forced-colors mode:
- Either you are building a graphic or chart, or more generally work in a fully controlled canvas and are already enforcing contrast one way or another, and need to avoid the remapping and backplating to screw it up; you therefore disable forced-colors intervention, and eventually use your own styles to address this somehow. This use case is already addressed properly at this point.
- The color-remapping and backplate do work for you globally. In one particular case, though, you know of some state that should affect the color remapping but isn't possible to convey in a way the browser heuristics would understand. You therefore want to specify one particular remapping yourself, while leaving the rest untouched. This doesn't seem very convenient to address today.

## Thoughts on proposals
While custom origins and !overrides would definitely enable to solve the second use case, I think they give more power than is actually required to solve the problem at hand here (including unfortunate footguns).

Aiming for more simplicity, I rather propose to add a third value to `forced-color-adjust` instead of adding a more generic complexity. I have two options in mind for the form this third value would take, and I would be interested to know what people at Microsoft who reviewed the use cases think of them.

**Option 1:** `forced-color-adjust: out-of-palette-only`
Under this proposal, the colors of an element are still adjusted to fit the palette accepted by the mode, but if the computed value of a color property happens to be in that system palette already, no modification is made to that color.

I believe this should cover the case presented above in this discussion without modification to cascade rules whatsoever.

**Option 2:** `forced-color-adjust: auto <foreground-color>? <background-color>?`
Under this more strict proposal, the forced-coloring is still applied, but instead of following heuristics, colors are mapped to `<foreground-color>` (color, border, ...) or `<background-color>` otherwise. Disabling the heuristics for that element (and its inheriting descendant unless explicitly respecified otherwise) makes the authors in control.

To avoid being painful, forms and replaced elements would have `forced-color-adjust: auto` speficied in the User-Agent stylesheet, so that they don't inherit a foreground-background combination aimed at a section of text instead (but authors can of course specify `forced-color-adjust: inherit` on them if that was intended.

This second proposal is more strict than the first one, but slighly more powerful in some cases if we don't restrict `<foreground-color>` and `<background-color>` to be in the palette (we could, though, in which cases it is more strict that option 1 and never more powerful).

**Are there known use cases that wouldn't be solved by either proposal?** (If not, my recommendation is to add this third value, and not fiddle with cascade rules in this scenario)

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

Received on Thursday, 30 April 2020 16:33:27 UTC