[various] Holistic review/proposal of color-modifying things

[tabatkins]

@fantasai and I have spent the day reviewing all the various proposals regarding modifying the colors on the page (dark mode, high-contrast, etc), and have come up with an integrated set of proposals that we think address all the use-cases and interact fairly cleanly.

"High-contrast" proposal

@media (forced-colors: none | active) {...}

forced-color-adjust: auto | none

Undeprecate some System Colors, and add a few new ones to match with MS's High Contrast feature (which isn't actually about high contrast, but rather about forcing apps/websites to use a specific, small set of user-chosen colors-- which may or may not be high contrast, and in some cases may specifically be low-contrast).

When forced-color-adjust is auto and the user is forcing colors, then the set of properties defined in the MS proposal have their colors overridden to use the system colors defined above. Authors are encouraged to use these system colors for properties that aren't overridden to create a coherent page design when colors are forced.

If the forced background is dark (based on Lab lightness), (prefers-color-scheme: dark) must match; mutatis mutandi for light. This way, websites that support light/dark color schemes will adjust automatically to more closely match the color scheme implied by the forced colors. (This replaces the white-on-black and black-on-white values of the MSFT high-contrast media query proposal.)

The (prefers-contrast) MQ is unrelated and unchanged.

(We might further consider folding 'forced-color-adjust' into the existing 'color-adjust' property somehow, but can discuss whether and how to do that later.)

Light/Dark color scheme proposal

@media (prefers-color-scheme: light | dark | no-preference)

color-scheme: only? && [light | dark | <custom-ident>]+

<meta name=color-scheme content="(same values)"> sets initial value of 'color-scheme' on the root.

Processing rules as defined by Rune https://lilles.github.io/specs/supported-color-schemes.html

If we can change system colors to compute to themselves, then 'color-scheme' changes the used values of the system colors on the element. If not, 'color-scheme' on the root does so for the whole page. In either case, the affected system colors are at least the set defined for "high contrast".

'color-scheme' must also affect input & scrollbar styling.

color-filter proposal

• Sydney 2018 discussion minutes
• Issue [filters] Proposal: color-filter #2875 for rough proposal

This seems like an early attempt at ability to auto dark-mode a page, but doesn't seem particularly useful now that color-scheme/etc has reasonable consensus.

It might be useful to expose as a quick-and-dirty way for an author to dark-mode their page, but are there use-cases beyond auto-darkmode-ing? If not, maybe just switch this to a keyword property (adding to 'color-adjust'?) that can do "smarter" inversion based on luminance.

inverted-colors proposal

@media (inverted-colors: none | inverted)

Supported in Safari; it's not clear whether "inverted" means all-pixels inversion, or color-inversion only, or what?

Important to distinguish these, as what authors do in response can vary based on which inversion is performed. (The img { filter: invert(100%); } rule in the spec's example, for instance, is only useful for all-pixel inversion; it would be harmful for a colors-only inversion.)

So, we either need to specify what kind of inversion is allowed to be performed, or add more values capturing the distinctions among the types.

[AmeliaBR]

I strongly support the goal of making the various media queries logically independent (e.g., having forced-colors separate from the light/dark mode, separate from high/low contrast preference). I think the proposals above achieve that goal for those features.

Authors can always use boolean combinations of media queries as needed, e.g. @media (prefers-contrast: high) AND (prefers-color-scheme: dark) AND NOT (forced-colors) { /* author's high-contrast dark scheme */ }

I'd recommend also splitting the relevant section of Media Queries 5 to clearly separate out the user preference media queries which ask the author to make changes (prefers-reduced-motion, prefers-color-scheme) from the media queries that advise the author that the user agent is making its own modifications and some minor adjustments may be required (forced-colors, inverted-colors).

I wonder if inverted-colors could be generalized as forced-filter, to also include "night light" effects that change the brightness and hue of the screen. e.g. @media (forced-filter: invert) vs @media (forced-filter: sepia) or just @media (forced-filter) to indicate that the user agent or OS is filtering the final rendered colors.

That would also avoid any confusion about how invert mode interacts with individual color values — it's a filter effect that applies to the full screen, although it is possible to revert the effect with opposite filters on individual elements. (I think this is how the Safari implementation works, with the "reverting invert" filters on images and videos now specified in the user style sheet. So specifying the same rule in an author stylesheet would have neither harm nor benefit. But someone who is familiar with the latest WebKit changes needs to confirm.)

The special cascade order rules for forced-color / -ms-high-contrast might also apply for forced-filter and other “forced” UA media manipulations. Whether this is necessary would depend on how many other user-agent style tweaks get added in those conditions. But for example, maybe I have an <img> that is a black line drawing on a white background and it should actually get inverted to white on black when the user has inverted the rest of the screen, so I want to use img { filter: none} to cancel out any user-agent stylesheet that double-inverts images.

[smfr]

@media (inverted-colors: none | inverted) is about the screen-level color inversion accessibility feature (possibly with some re-inversion of images/video). It's a mode in which individual colors can't be independently adjusted; it's akin to a filter:invert() on the document.

[FremyCompany]

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]
  ✔ (no more comment)

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

[AmeliaBR]

I am very intrigued by @FremyCompany's suggestion re using revert instead of the proposed cascade manipulation.

To clarify, this would mean that turning on a high contrast mode or other forced-color effect would have the following effects:

• Change the system colors (& make any extra changes to the user agent stylesheet that can't be handled just by system colors).
• Trigger the forced-color media condition.
• Set forced-color-adjust: auto on the document root (so it inherits into the whole document unless the other overrides it). This could be represented by a conditional rule in the user agent stylesheet:

  @media (forced-colors) {
    :root { forced-color-adjust: auto }
  }

From there, all values from the user agent and author stylesheet would cascade as normal.

After cascade — and separate from whether a high contrast mode is on or not — the forced-color-adjust property would have the following effects when it computes to auto:

• revert any author-specified values on the element for the list of color-related properties
• Add a solid-color text backplate (that matches the system background color) behind any text glyphs rendered for the element.

I do like this approach, especially if the existing ms media query can be made to work with it (with minimal magic).

I would suggest that auto is no longer the best keyword for something that causes a change by itself. Maybe forced-color-adjust: on vs off makes more sense? But then again, sticking with the auto and none keywords makes it easier to define the Microsoft high-contrast-adjust as a direct synonym.

[grorg]

@media (inverted-colors: none | inverted) is about the screen-level color inversion accessibility feature (possibly with some re-inversion of images/video). It's a mode in which individual colors can't be independently adjusted; it's akin to a filter:invert() on the document.

To give a bit of history, this was originally offered as an accessibility feature and implemented at the system level - in that apps couldn't opt-out, and didn't even know it was happening unless they queried the system preferences (which I guess technically gave them a way to opt-out by pre-inverting things before they draw).

It was a popular feature, but the main complaint was that inverted images are wrong. So then came "smart invert", where everything was inverted except images and other media

Then we discovered that people would toggle this feature on and off depending on the page content. Basically they wanted either dark or light pages, and prefer to have their choice even if that meant the colours are all weird. So that's where we are today, and led to having a system preference for light/dark.

If the light/dark preference becomes widely adopted, we might not need the invert path any more.

[emilio]

I have various complaints about the high-contrast stuff:

• The ability to override user preference using high-contrast-adjust that @MatsPalmgren has objected to in the past.

• The dependency between high-contrast-adjust and basically all the color properties means that it's yet another property that needs to be cascaded early, which is not fun (probably wouldn't be a blocker though).

• I find the @media block thing extremely weird / over-complicated. If we want to go that route, we also need to handle <link media="">, <style media="">, @import url(...) <media>, and all dynamic changes to those via the OM or attributes. I think implementing that properly is going to be a huge pain, and it really feels overkill for such a feature. I personally would prefer a simpler solution.

Regarding @FremyCompany's proposal of using revert, we probably would still need the extra priority to determine whether the value is auto anyhow, since we don't have the concept of cascaded values vs. computed values, we compute as we do the cascade. But it's the same complexity as the other model, and revert would respect user stylesheets (though again the first model condition about UA sheet could be made to respect user stylesheets as well).

[fantasai]

@emilio Please, let's not continue to call this “high contrast”. Rossen has already pointed out that it's also used to enforce low contrast; we need to be clear when discussing it that it is not synonymous with a request for high contrast.

Wrt not being able to override... the user could theoretically set * { forced-colors-adjust: auto !important; }, which would prevent the page from making any customizations. I don't know too much about the use cases that prompted this property, but my inclination is, if MSFT has found this property to be necessary, we'll probably need to include it. However, I think they did find that usage declined significantly with their current version of the feature, so maybe it's not needed anymore. If they're continuing to ship it, though, I would like us to standardize it.

@grorg Dark mode is interesting, and I imagine in some cases it might be a user's base preference and for others they might prefer enforcing it. If inversion (rather than forced colors) is the path you're choosing for enforcement, I imagine you might end up with an option for "let the page do as it likes if it supports the appropriate color mode, otherwise invert". The media queries we have can express this state in case the author wants to query it and make adjustments... except we're not clear on the method of color inversion. If the author needs to invert images, or if it can depend on the UA doing so, or if hues will be distorted or preserved, those are important distinctions we need to be able to make. In other words, the inverted-colors MQ needs to be specific enough that the expected work the author needs to do is very clear and does not need to differ depending on the UA/OS/version, only on MQ values that they can legitimately query!

[FremyCompany]

The main reason the property is still needed, is that if you are building your own component, you need to be able to set the color of the text in that component to "DisabledText" when your component is disabled otherwise it becomes inacessible. Ditto for other custom states.

[css-meeting-bot]

The CSS Working Group just discussed Holistic review/proposal of color-modifying things, and agreed to the following:

• RESOLVED: start a new Color Adjust draft
• RESOLVED: Add forced-colors MQ to MQ spec
• RESOLVED: Add forced-color-adjust property as an opt to into new spec

The full IRC log of that discussion

<dael> Topic: Holistic review/proposal of color-modifying things
<dael> github: https://github.com//issues/3807
<dael> TabAtkins: fantasai and I have been watching with mild concern as various color modifying things have come about. Wanted to make sure they all corrdinated. Put together an issue that reviews all of it. For the most part people are doing same and that's good. Have a few suggestions that are minor
<dael> TabAtkins: Dark mode- The spec Rune put together based on our plan which basically matches Safari is good except long names. Hvae suggested shorter names. preferred-color-scheme we wanted to call color-scheme. That's about it for dark mode.
<fantasai> s/preferred/supported/
<dael> TabAtkins: MS high contrast prop works pretty well
<dael> TabAtkins: Set of system colors we support has a few with appropriate names. Outlined those in issue with additional color names if we want to give access to authors via MQ
<dael> TabAtkins: If doing forced color scheme and bg is light or dark should also trigger light or dark mode MQ.
<dael> TabAtkins: You can do things like remove shadows based on it being dark or whatnot
<dael> TabAtkins: Question about inverted colors, but should discuss sep
<dael> TabAtkins: Main thing. Suggestion of modified names
<dael> TabAtkins: [missed...audio issues]
<dino> 🎁+
<dael> TabAtkins: Main thing is first this suggested shortened name for dark mode and meta tag. Only shipping impl is Safari b/c they shipped before a spec. No one else has shipped. So resolution if we change names or not.
<dael> smfr: Reason we choose prefers; we need to make clear to authors this is user's preferred appearance for the page. Similar to preferred reduced motion MQ.
<dael> TabAtkins: MQ is good. It's supported-color-scheme property and meta we want to rename.
<fantasai> @media (prefers-color-scheme: light | dark | no-preference)
<fantasai> color-scheme: only? && [light | dark | <custom-ident>]+
<fantasai> <meta name=color-scheme content="(same values)"> sets initial value of 'color-scheme' on the root
<fantasai> proposal ^
<dael> dino: I was going to say MQ has been in MQ spec for a long time
<dael> astearns: Given that, smfr is rename okay?
<dael> AmeliaBR: It's drop 'supported' in 'supported-color-scheme'
<fantasai> If we can change system colors to compute to themselves, then 'color-scheme' changes the used values of the system colors on the element. If not, 'color-scheme' on the root does so for the whole page. In either case, the affected system colors are at least the set defined for "high contrast".
<dael> florian: But not for MQ?
<fantasai> 'color-scheme' must also affect input & scrollbar styling.
<dael> AmeliaBR: MQ keeps 'preferred'
<dael> smfr: Think okay
<fantasai> s/preferred/prefers/
<dael> fremy: Wondering, on the issue color-scheme is written as a singular. Is that intentional?
<dael> TabAtkins: Property names are always singular so we went with that.
<dael> fremy: Okay, sounds good. If you thought about it I'm fine
<dael> astearns: Other discussion on if we should have 'supports' in prop name?
<dael> dino: Not changing values, jsut removing prefix?
<dael> fantasai: We also fixed the grammar. Current allows light or dark or only keyword. Defined to parse and not throw out additional IDs.
<dael> TabAtkins: As far as we know this matches what you intended
<dael> smfr: Sounds fine
<fantasai> Proposal is to rename supported-color-scheme to color-scheme
<dael> dino: Reading in #3807 in light/dark color scheme proposal. That's what to look at?
<dael> TabAtkins: Yeah
<dael> dino: I think we're okay with that
<dael> smfr: Allow only to be at end?
<dael> TabAtkins: Either spot because it matches general CSS. only light and light only make sense
<dael> astearns: Other questions about change from supported-color-scheme to color-scheme ?
<fantasai> smfr, you can't do "light only dark"
<fantasai> smfr, but "only light dark" and "light dark only" are fine
<dael> Rossen_: Reviewing this prop it aligns closely with some internal work we did on this in terms of wordsmithing and aligning. Thanks for taking the time TabAtkins and fantasai. It aligns with how I hoped this would mash together and make sense of all the darks and lights. +1 and thank you
<dael> astearns: Prop: Add the color-scheme property with updated grammar to a spec instead of supported-color-scheme
<dael> TabAtkins: Yes. Not sure if there's an existing spec that fits. Maybe colors but I'm not sure. Either Colors or a new spec
<dael> AmeliaBR: THis goes into larger discussion. Debated last week where adjust for forced colors goes. Maybe in same place as new color-scheme
<dael> TabAtkins: Yes. High contrast stuff should be same place as light/dark. That should be either Color or a new spec
<dael> florian: Feels coherent enough to be a sep spec and feels it will move faster
<dael> fantasai: Discussion was appendix to MQ until we figure out where it goes
<dael> AmeliaBR: Other property these are related to is appearance. It's turning on or off default UA styles. Not sure what spec that's in
<dael> florian: That's CSS UI L4. It's a bit of a stretch but only a little one
<dael> TabAtkins: Can we make a color adjust spec?
<dael> fantasai: Sure
<fantasai> s/make/just make/
<dael> Rossen_: We can always have one more spec :)
<fantasai> s/color adjust/color-adjust/
<dael> astearns: Obj to start a new Color Adjust draft?
<dael> RESOLVED: start a new Color Adjust draft
<dael> astearns: Who will edit?
<dael> TabAtkins: fantasai and I
<dael> astearns: Who else
<dael> Rossen_: Rune and I should put time on this and put our edits
<dael> tantek: sgtm
<dael> s/tantek/Tab
<dael> astearns: I'm appointing Rune and Rossen as editors, TabAtkins and fantasai can provide feedback. Let's spread out editing
<dael> Rossen_: Resolutions for MQs?
<dael> astearns: Let's resolve on color scheme. Obj to Add the color-scheme property with updated grammar to Color Adjust spec instead of supported-color-scheme
<dael> AmeliaBR: Meta tag too?
<dael> astearns: Yes
<dael> dbaron: I think I said what I didn't like last time we discussed this.
<dael> florian: Don't think resolved
<dael> dbaron: My concern is we have a set up where all pages on web work with light form controls. Many pages break with dark. On systems where browser can choose they tend to light.
<dael> dbaron: This is designing around a few recent OS changes rather than say a general system them change a user has made. It's not clear to me this is impl across OS themes. It's a step forward and backward. All pages work with light, many broken in dark. this allows pages to say work with dark, but also allows broken in light and i"m not happy about that
<dael> dbaron: Want to have a page say I'm happy with a dark theme. Not happy about page overriding user choice
<dael> AmeliaBR: You okay taking this up in spec discussion? Sounds like you're concerned about the only keyword interacting with list of preferences. I'm not sure that blocks actual concept
<dael> dbaron: Once there's a spec it will ship. WE need to discuss before
<dael> fantasai: Well it shipped w/o a spec
<fantasai> already
<dael> astearns: Would concern be addressed if we did grammar such that you could not exclude supporting a light scheme?
<dael> dbaron: I believe so. I'm not up on semantics of current proposal.
<dael> TabAtkins: Ignoring future compat with other schemes. IT's saying I'm fine with light or dark or I'm only fine with light or only fine with dark. If at the moment 'only' works on light you can say I only do light or you can say I allow dark and if user wants that give it to me
<dael> astearns: That does seem more widely implementable
<dael> dbaron: I think that would help
<dael> dbaron: Still some edge cases where we couldn't do that
<dael> florian: Neither light nor dark systems?
<dael> dbaron: Or we don't know. We can just draw a control.
<dael> astearns: Another way addressing this is to have an implicit auto where there is a browser default that this prop cannot opt out of.
<dael> astearns: If the color scheme is set to only dark if browser only has one set of form controls it can display with those auto controls
<dael> AmeliaBR: THat's clear in Rune spec. It's a matter of if browser has >1 color scheme the only is asking author pref to override user. BUt it presumes >1 color scheme
<dael> TabAtkins: Per current processing if you only have 1 color scheme it selects that. Only filters to values unless the set would be empty
<dael> dbaron: Nice spec says that but reality is if 99% browsers have both the 1% will have to do something b/c otherwise pages break
<dael> florian: That's the situation today. If your UI is orange on pink too bad for you.
<dael> dbaron: I'm concerned about Linux. Most users have light form controls. Edge case will expand from set of Linux users with dark controls to all Linux users
<dael> TabAtkins: On pages that are only dark and break in a bad way with a light form control
<dael> TabAtkins: Those don't exist now so it's theoretical future pages
<dael> astearns: How about this. Resolve on putting color scheme in the spec with an issue noting we are concerned about backwards compat and need some way of expressing that it is okay to display things with the controls you've got
<dael> florian: Prefer to start with restricted grammar. Then if we relax later it's easier.
<dael> AmeliaBR: Restricted grammar is do not allow dark only. You can say light only or light and dark but you can't say an only that doesn't include light.
<dael> florian: Yes
<dael> fremy: I still don't...it's removing a possibility that's a legit use case. We are assumign this new feature that doesn't work well on an OS that can chnage. If this becomes a problem Linux can do what every other system does and fix it.
<dael> florian: Compat problem. It's about writing a web page that says it doesn't work on existing OSs
<dael> fremy: That happens all the time. You need a webcam to do a skype call. I don't like spec around limitations of one system
<dael> astearns: CSS is long lived. I can see a new OS that's very concerned about its controls and it will never show a dark mode.
<dael> Rossen_: Are we solving anything? Feels like we're rambling
<dael> astearns: Current suggestion is we put color-scheme in with a change to grammar such that you can only express the only keyword for the light theme
<dael> astearns: Heard concerns it's too restrictive. But it can relax in future
<dael> fremy: If you have a toggle on website that says I want dark theme you can't have dark form controls.
<dael> florian: You can ask for dakr, just not on OSs that can't do it
<dael> fremy: Doesn't work. If you have a website with a toggle and user clicks I want dark theme if the OS has a light you get light
<AmeliaBR> For clarification, I am not supporting the "restricted grammar". But I am very supportive of adding the property to the spec with an open issue.
<dael> fantasai: We're either adding this or not. Apple has shipped. Might be able to get away with not adding only, but we can debate on another day
<dael> fremy: So you can still do dark light for what I want
<dael> resolved: Add the color-scheme property and meta with updated grammar and no 'only' property to Color Adjust spec instead of supported-color-scheme
<dael> fantasai: MS had what they called high contrast MQ and high contrast adjust but they said same is used for low contrast so calling it high contrast is confusing
<dael> fantasai: TabAtkins and I suggest calling it forced-colors
<dael> fantasai: MQ for forced-color-adjust. Rather than diff keywords color scheme relying on dark mode switch so only none or active in the MQ
<AmeliaBR> Strong +1 to the forced-colors name
<dael> astearns: Concerned it's too abstract. contrast-adjust might be better
<dael> fantasai: Not adjusting. This is fixed colors and we're forcing on you
<fantasai> s/fixed colors/fixed set of colors/
<fantasai> @media (forced-colors: none | active) {...}
<florian> I like forced-colors
<fantasai> forced-color-adjust: auto | none
<dael> Rossen_: Forced color desc well. Another name is user-color-scheme. That implies user choose that and only problem is too close to prefers-color-scheme. Forced-colors is fine
<dael> astearns: Other concerns?
<dael> florian: Question- earlier talked about interact with prefers-color-scheme have prefers-contrast, interact?
<fantasai> "The (prefers-contrast) MQ is unrelated and unchanged."
<dael> fantasai: prefers-contrast is same and nothing changes
<dael> TabAtkins: It's orthogonal which is why want to get away from work contrast
<dael> florian: But if forced color scheme has something dramatic you can infer prefered contrast
<dael> TabAtkins: Prefers contrast is different.
<dael> AmeliaBR: Important to keep naming clear. Have set of prefers MQs that tells author user expressed a preference. forced-colors is very different so it's important to have a very different name that emphasizes the override. Also really important that it doesn't make any assumptions about what hte colors are
<fantasai> TabAtkins^: prefers-contrast is about letting author adjust things to match the contrast preferences. This is about you're using this set of colors, too bad.
<dael> AmeliaBR: Key feature for authos is that you're not going to know what colors will be used
<aja> fwiw, implementers, consider support for :has along with the meta, eg :root:has(meta) {--set-some-variables-on-root}}
<dael> florian: Not opposed. Little confused why you can infer prefer high if it's dark but can't infer prefer light
<dael> fantasai: What about lime green on pink. What does that mean? Is it high or low?
<dael> florian: Weird contrast ^-^
<dael> fremy: Agree with florian . Should be in spec. UA can decide to do these things, but we shouldn't spec it. User is allowed to decide they want high contrast. You can put a note saying you can be smart. I like proposal of not forcing this but UA can do smart things
<dael> florian: I'm sold
<dael> Rossen_: Can we go back to forced-colors and not talk contrast?
<dael> astearns: Is high contrast prop in a spec?
<dael> Rossen_: Which? One we prop?
<dael> fantasai: One you prop. There's enough explainers we can write a spec.
<dael> astearns: Prop: Add a forced-colors MQ into the new draft?
<dael> Rossen_: Or MQ, whichever
<dael> fantasai: In MQ
<dael> TabAtkins: Forced-color MQ into MQ spec
<dael> astearns: Objections to adding forced-colors MQ to MQ spec
<dael> RESOLVED: Add forced-colors MQ to MQ spec
<dael> astearns: forced-color property in the new spec
<dael> TabAtkins: Indicates on a sub tree don't force colors I know what I'm doing.
<dael> Rossen_: Should go in color adjust
<dael> Rossen_: Fitting to be in color adjust spec
<dael> florian: Presumably the adjust thing on print goes with it?
<dael> fantasai: We should move it, yeah
<dael> astearns: Obj to adding forced-color-adjust property as an opt to into new spec?
<dael> RESOLVED: Add forced-color-adjust property as an opt to into new spec
<dael> AmeliaBR: In draft from Rossen_ and melanierichards lots of issues about interaction between author and UA will go. Is that into new spec?
<dael> TabAtkins: Yes
<dael> AmeliaBR: fremy had diff prop for same thing so that discussion would happen in this spec?
<dael> TabAtkins: Yep
<dael> astearns: We'll have continued discussion for this new spec, what goes in , and changes
<dael> fantasai: Reoslve to move print-color-adjust?
<dael> astearns: Obj?
<dael> resolved: Move print-color-adjust property into the new spec
<dael> astearns: I'll leave agenda+ on the new items