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

[fantasai]

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?

[AmeliaBR]

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:

: 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.

[dbaron]

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.

[fantasai]

@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.

[css-meeting-bot]

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

The full IRC log of that discussion

Topic: Combine forced-color-adjust and color-adjust properties somehow?
github: https://github.com//issues/3880
astearns: Was on F2F, didn't get to it.
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
fantasai: If anyone is interested keep track of issue. Someone needs to make a proposal before we can move forward
astearns: Anything else before we punt?
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
chris: I think they're better separate. dbaron comment is on the money there
astearns: fantasai think we should close no change?
fantasai: I'd give another couple weeks to see if we can solve dbaron concerns and if not we close it.
astearns: Any other comments?

[alice]

Coming here from the TAG review for css-color-adjust-1.

We are also curious about the reasoning behind not combining these two. I see @dbaron's comments above, but I think more investigation is warranted as to whether the mitigations in each scenario are similar enough that they're not worth keeping separate, only to end up duplicating styles or failing to handle one or other scenario.

[css-meeting-bot]

The CSS Working Group just discussed Combine forced-color-adjust and color-adjust properties somehow?, and agreed to the following:

• RESOLVED: no change, keep both forced-color-adjust and color-adjust

The full IRC log of that discussion

Topic: Combine forced-color-adjust and color-adjust properties somehow?
github: https://github.com//issues/3880
leaverou: I was in the breakout, there are many use cases where you want both. should be an easy way to enable both
leaverou: perhaps a shorthand would provide flexibility
TabAtkins: i think these are sufficiently different that we shouldn't turn them off at one. printing well is conceptually similar but different that color adjustment for forced colors
TabAtkins: wouldn't want to trigger one, but accidentally the other (i.e. if authors optimize for screen media, not print)
TabAtkins: suspect they shouldn't be done at the same time
Rossen_: in two environments, the properties have almost opposite effect (on-by-default vs. off-by-default)
Rossen_: historically they have different usage as well, increasing adoption, i'm on the side of keeping these separate for the same reasons
fantasai: agree with reasons to keep them separate. color swatches is a use case for using them in both situations.
fantasai: would be nice for authors be able to have something that works for future color adjustments, but currently color-adjust is specific to print
s/a use case/the one use case I can think of /
Rossen_: Proposed resolution no change - any objections?
RESOLVED: no change, keep both forced-color-adjust and color-adjust

[emilio]

Err, was going to close mozilla/wg-decisions#515 (though this one should probably be closed as well)

[fantasai]

@alice We're closing this as no change because we don't have a good idea for how to do this in a way that doesn't introduce problems. Considerations are:

• color-adjust has been shipping for quite awhile, used to get backgrounds to print, so we need to continue to support the current syntax.
• Elements that have color-adjust to get backgrounds to print should, for the most part, still be affected by forced-colors mode, so we can't combine the two into one switch.

There's one use case where pretty much any imagineable color adjustment (the ones that exist, and ones we might invent in the future) should be turned off: color swatches. It would be nice if there was some way to indicate this without encouraging authors to overuse it.

But overall it seems like pages are more likely to make errors if we cascade these two switches as a single property than if they are separate. :(

[LeaVerou]

color-adjust has been shipping for quite awhile, used to get backgrounds to print, so we need to continue to support the current syntax.

I just looked at the Almanac 2020 data, and color-adjust is only used in 0.25% of pages. Actually, print-color-adjust, a nonexistent (?) property is used in 0.17% of pages, which indicates how incredibly confusing this name is (I'm assuming people were going for color-adjust, but forgot it doesn't have print- in the name, even though that's what it's about). Lastly, -webkit-print-color-adjust is used in 1.19% of pages.
I don't think there's a huge web compat cost to changing the name.
I'm not even sure print-color-adjust would be a good name, since whether backgrounds print is not about adjusting colors at all…

• Elements that have color-adjust to get backgrounds to print should, for the most part, still be affected by forced-colors mode, so we can't combine the two into one switch.

There's one use case where pretty much any imagineable color adjustment (the ones that exist, and ones we might invent in the future) should be turned off: color swatches. It would be nice if there was some way to indicate this without encouraging authors to overuse it.

But overall it seems like pages are more likely to make errors if we cascade these two switches as a single property than if they are separate. :(

What about making color-adjust a shorthand of print-color-adjust (name TBB) and forced-color-adjust?
Depending the specifics of the shorthand syntax, that could also mitigate any web compat issues.

[tabatkins]

Note that 0.25% is far above our threshold for potential breakage. That's an enormous number of pages.

[fantasai]

@LeaVerou It's not just about getting backgrounds to print: UAs do automatic adjustment for e.g. light on dark pages to flip their colors so they'll print readably without using all the ink.

That said, I wonder if we should add print-color-adjust as an alias.

[tabatkins]

Agenda+, specifically, to discuss the option of moving the name to print-color-adjust, and leaving the excessively-generic color-adjust as a deprecated alias. We switched to the generic name back when we thought we might do more color adjustments in the same property, but that hasn't panned out and we don't think it's a good idea any longer.

[css-meeting-bot]

The CSS Working Group just discussed [css-color-adjust-1] Combine forced-color-adjust and color-adjust properties somehow?, and agreed to the following:

• RESOLVED: Add print-color-adjust as an alias for color-adjust and have the generic color-adjust be deprecated

The full IRC log of that discussion

Topic: [css-color-adjust-1] Combine forced-color-adjust and color-adjust properties somehow?
github: https://github.com//issues/3880#issuecomment-839880816
TabAtkins: Been an issue for a long time wondering if we can combine the properties and generalize into a larger thing that controls color adjustments
https://github.com//issues/3880#issuecomment-816280715
https://github.com//issues/3880#issuecomment-816275920
TabAtkins: After discussion fantasai and I concluded we shouldn't b/c addressing different issues. Don't think appropriate to make it easy to turn them all off at once
fantasai: And have WG resolution on this
+1 to print-color-adjust
fantasai: Reason it's on agenda is leaverou brought up information about color-adjust property and looking at data. That color adjust mostly affects print but has generic name it seems like it should be shorthand. There was webkit print color adjust. Looking at that wondering if should call it print-color-adjust and leave color-adjust as a deprecated alias
fantasai: Reason it was generic is we thought it would be a generic switch but it doesn't end up working well. Having a generic name is more confusing than helpful
+1 to print-color-adjust
q+
astearns: Seems reasonable to be more specific, though have to support both
ack florian
q+
florian: Wondering while not fully generic are we sure it's not more generic than print? Not wasting energey for screens with different profiles. There might be adjustments similar to print but not actually print. Or are we ruling those out?
fantasai: Good point but majority of use is for print.
ack smfr
smfr: There is a potential applicaiton. If we do HDR colors they have a power usage impact so this may allow authors to decide if high energy colors are allowed
florian: Thanks for a more concrete example. Could a default be surpress and opt in or no default surpression?
q+
ack chris_
smfr: Haven't decided yet. Maybe prevent cross-orgin. Who knows
chris_: Impl require an explicit request for HDR current. I think that would be the case here
florian: So could be applicable?
chris_: Certainly
florian: Should we punt and explore that topic? Or is there time pressure?
fantasai: 2 open issues on color-adjust. One is waiting on review and the other we just discussed. Not much time pressure
astearns: Point of moving the name is to disabuse that color-adjust is a shorthand?
fantasai: yeah
astearns: Pretty weak to add another name
fantasai: And that people are using it and WK is -print-
florian: We're aliasing through shorthanding so we could add highdef color adjust and then color-adjust is a shorthand
astearns: Deprecate the generic until we have a need and than undeprecate?
chris_: I like combining the 2 if we need it
florian: And can do separately
florian: Introduce print, make the non-specific a shorthand but call it deprecated for now
astearns: Arguments againt?
astearns: Prop: Add print-color-adjust as an alais for color-adjust and have the generic color-adjust be deprecated
RESOLVED: Add print-color-adjust as an alias for color-adjust and have the generic color-adjust be deprecated