Elika: This one might warrant a full TAG review. It was also drafted more recently, and only has 3 major features, so much easier to pull out the relevant points.

... grid would be a much taller order to explain, for example.

Rossen: I'm deeply involved in this spec... need to recuse from reviewing but I can provide context.

... looking at the call here and basically everyone on the call is close to this issue one way or another.

Alice: ...

Rossen: color-scheme... light or dark currently, few different ways authored content can fall into a color scheme. Might come directly from OS setting, has a global application of color scheme, forced or opt-in comes down to OS implementation.

... Windows supports both forced color scheme from a11y settings, colour reduced down to a few system colours, improving readability and cognitive load.

... other one is preferred scheme such as dark and light, which are deliberately undefined; dark may be dark blue, dark brown ...

... looked at color scheme property, convinced ourselves that dark and light are the only color schemes we really need to support to accommodate modern OSes and browsers.

Alice: already a MQ for dark mode, right?

Rossen: that will evaluate whenever color-scheme is dark.

Alice: What does the property add on top of the MQ?

Rossen: Can be in dark mode, but then force colours that are light... force-colors MQ will be true, color-scheme light... dark mode will go away.

Lea: Are the use cases more like I don't want dark mode on this part of the document, or more like I do want light mode... more opt in or opt out?

... Examples in the spec say you should list out all the idents... not future-proof. If a new color scheme is listed, it's assumed I want to opt out of it.

Alice: Examples in spec also use the exact same code snippet for two different scenarios, and it's not clear what is consuming the property.

... color-adjust...

Lea: There is an open issue (#2) about whether these properties should be merged... color-adjust basically mainly applies to printing... seems like an overly generic name for a specific thing. What about making it a shorthand, of perhaps color-adjust-forced and color-adjust-economy?

Peter: May want these things to cascade differently... forced-color-adjust more likely to apply to specific elements.

Rossen: color-adjust is a legacy property for printers, has existed for many years. Ideally wouldn't be generic at this point. forced-color-adjust is quite a different use case, applies to an element and its subtree.

... since color-adjust was already there, we decided to reuse and combine it (with forced-color-adjust.

Peter: historically browsers would not print backgrounds; color-adjust allows you to opt in to printing backgrounds (for example).

Rossen: drifted away from color-scheme topic.

Alice: I'm going to leave a comment on that one.

Lea: does forced-color-adjust and color-adjust have the same basic use case (albeit in different context)? Could they be something like color-preserve?

Rossen: Opt in vs. opt out behaviour... opt-out is forced-color-adjust, you can opt out of the forcing

Alice: you revert to the non-forced colors...

Lea: it's an opt-out in both cases?

Rossen: color-adjust is an opt in (exact value)

Peter: use color-adjust when you have a background on something that really needs to be printed. e.g. you're printing a list of driving directions and need zebra striping.

... forced-color-adjust, the browser is flipping the color of the scrollbars

Lea: significant intersection in the use cases, e.g. color swatches you would want to both display and print them.

Alice: seems like color-adjust and forced-color-adjust have the same effects?

Peter: economy mode is going to suppress backgrounds. forced-color-adjust affects default colors.

... If we were going to combine, UA stylesheet would need to specify the default behaviour in each context.

Alice: Took a look earlier and didn't see any comments since my last feedback. Noticed that they want issues in their repo, so I'll go ahead and transfer the issues there and wait for a response.

Lea: there haven't been any updates since discussion with Alice. Alice opened a bunch of issues in CSS wg repo which are still open. Most have not received comments. No responses in the TAG issue.

Lea: adding labels to issue to indicated pending external feedback

[bumped 3 weeks]

Pending feedback, bumped.

Still pending feedback from the CSSWG

Lea: this is a very confusing name

hadley: agreed

Tess: especially when the main issue is "should my background image print?"

[discussion on Alice's question: One thing that I note is that "normal" is more or less synonymous with "light", in practice. Why have two values which mean roughly the same thing? Could "normal" be replaced with "light" as the default?]

Tess: It seems the WG looked at it and decided that on some devices (like TVs), normal is actually dark rather than light.

They have considered all of Alice's feedback, have come to conclusions on all of it. I'm satisfied that they've considered it all. Not sure if Alice would agree. But I'm inclined to say okay.

Agreed: we'll propose closing it

Draft closing comment:

Hi @fantasai, @TabAtkins!

Hadley, Lea, and I took another look at this during a breakout this week. Overall we're happy with this set of features that solve a number of real problems. @alice raised a number of points, and we see that the WG has considered each of them.

Thanks for bringing this to us!