Csswg-drafts: [css-color-adjust-1] Combine forced-color-adjust and color-adjust properties somehow?

Created on 27 Apr 2019  ·  4Comments  ·  Source: w3c/csswg-drafts

The forced-color-adjust and color-adjust properties are both switches for opting out of a form of forced color modification. Is there an ergonomic way (in terms of the cascade) to combine them?

Needs Design / Proposal css-color-adjust-1

Most helpful comment

I'm inclined to think that these are separate things that should stay in separate properties. I think the risk of combining them is that some pages whose authors have carefully considered how printing should work will work badly for users with accessibility needs related to color contrast, and pages whose authors have carefully considered how they should work for users who require high color contrast will waste a lot of ink when printed.

All 4 comments

In terms of the cascade, the questions (and my best guesses for answers) are:

  • Would an author ever want to insist on exact color rendering for one situation but not the other?

    Yes. If the author was turning off automatic forced-color adjustment to apply a more nuanced version of the system colors (e.g., for custom form controls or SVG diagrams), but the actual colors don't have specific meaning & could safely be adjusted when printing. Or if the author cared about the aesthetics of their brand colors, but not to the point of overriding accessibility.

  • Would an author want to toggle the values based on independent factors instead of setting both at once?

    Possibly, but I can't think of a good example. Both controls are very much content-based; neither should be applied blindly as a global page style.

  • Can the two be combined into a set of keywords that is intuitive to use?

    See below.


Initial syntax for a combined color-adjust property, as a strawman:

<color-adjust>: any | never [ economy || forced ]?

any would be the default and would mean that the user agent can adjust colors whenever it deems that the change is in the user's best interest.

never on its own would mean "not unless the user very explicitly over-rides the page or print-preview styles".

The other keywords _combine_ with never to indicate the specific cases where the user agent should not make adjustments:

  • never economy means that the user agent should not adjust colors for print economy.

  • never forced means that the user agent should not apply forced color values.

The list of specific situations could be extended in the future, which is why I also allowed never economy forced and never forced economy as valid declarations (currently equivalent to never on its own).

This arrangement is a little different from most CSS properties, because we want the default to be to allow everything, and we want authors to carefully think about which values they are disabling.

The downside is that authors might just use never everywhere because it is shorter, instead of thinking carefully about the situations they are disabling.

I'm inclined to think that these are separate things that should stay in separate properties. I think the risk of combining them is that some pages whose authors have carefully considered how printing should work will work badly for users with accessibility needs related to color contrast, and pages whose authors have carefully considered how they should work for users who require high color contrast will waste a lot of ink when printed.

@dbaron Yeah, we'd need to express the values in a way that trying to turn off a specific type of adjustment doesn't turn off all of them.

The CSS Working Group just discussed Combine forced-color-adjust and color-adjust properties somehow?.

The full IRC log of that discussion
<dael> Topic: Combine forced-color-adjust and color-adjust properties somehow?

<dael> github: https://github.com/w3c/csswg-drafts/issues/3880

<dael> astearns: Was on F2F, didn't get to it.

<dael> fantasai: I think this would have been better at f2F. I don't know if there's anything for call. We need a concrete prop to discuss on a call that handles this issues

<dael> fantasai: If anyone is interested keep track of issue. Someone needs to make a proposal before we can move forward

<dael> astearns: Anything else before we punt?

<dael> AmeliaBR: I have a rough prop in the issue. More I think the more I think it's not worth it. I would be comfortable resolving no change but we can leave the issue open pending a good proposal

<dael> chris: I think they're better separate. dbaron comment is on the money there

<dael> astearns: fantasai think we should close no change?

<dael> fantasai: I'd give another couple weeks to see if we can solve dbaron concerns and if not we close it.

<dael> astearns: Any other comments?

Was this page helpful?
0 / 5 - 0 ratings