[css-color-adjust-1] more granular overriding of forced colors mode than per-element

[melanierichards]

Somewhat combinatorial between specs, but css-color-adjust-1, Forced Color Schemes might be the best place to put this.

It would be ideal if an author could override a property value affected by forced colors without requiring the author to set forced-color-adjust to none on the element.

In some cases, authors will want to fully manage how an element is styled in forced color modes, which is an appropriate use of forced-color-adjust. But in other cases, they may just want to change a singular property value without interfering with other UA forced color styles, e.g.:

@media (forced-colors: active) {
  [aria-disabled="true"] {
     color: GrayText;
  }
}

We should perhaps tweak cascade expectation in Forced Color Schemes such that cascaded values outside of the forced-colors media query are unset, but origin override rules apply when additional styles are set within a forced-colors media query block. Essentially want to ensure that point 4 of the Cascade Order in the initial High Contrast explainer is true in standard implementations of forced color modes.

[FremyCompany]

I personally disagree with this.

[emilio]

Yeah, I think making declarations apply or not whether they're in a media query block is pretty confusing.

[atanassov]

@emilio can you expand why you believe such declarations are confusing?

The intent of the request is to allow declarations to work as expected inside a media query block, including forced-colors. The use of forced-colors-adjust is a pretty heavy hammer that is intended to put the author in charge of the element and all its descendants. In contrast, honoring the declarations inside forced-colors media query allows individual properties to be set just like you would inside prefers-colors-scheme for example.

[AmeliaBR]

they may just want to change a singular property value without interfering with other UA forced color styles

This seems like a dangerous thing to do, anyway. If an author changes foreground but not background colors (or vice versa) based on what they expect a "high contrast" mode to do, it could break very badly in a different forced colors mode.

The specific case of being able to indicate grayed text, using system colors, is valid, but is it really that much harder to also set the forced-colors-adjust: none and the matching background color (buttonFace or field)?

There's also nothing stopping a UA stylesheet from selecting on ARIA attributes when applying the forced color mode, if you're seeing this problem (ARIA semantics being lost in high contrast) a lot in the wild.

[atanassov]

The ergonomics of setting forced-colors-adjust: none are pretty bad if an author wants to adjust a single, targeted property. We heard strong author feedback on the issue from framework developers and looking further into it I agree it doesn't make sense to penalize them in these cases.

In the case of components where an author wants to opt-out and have complete control over it (ex. maps widget rendered in Canvas) the property makes complete sense.

[fantasai]

I agree that rules inside an MQ shouldn't be special. In particular, it's hard to know what rules are inside an MQ -- entire style sheets can be imported via several levels of @import indirection through a mediaquery-filtered link.

One possible way around this could be the author specifying which properties to except, e.g. forced-color-except: border stroke. Otherwise we're looking at a lot of magic in the cascade, I think.

[tabatkins]

I assume you mean "shouldn't be special", @fantasai ^_^

But yeah, we've avoided giving special meaning to things inside of MQs for a long time for several reasons, and I think we should continue avoiding that.

[lilles]

I agree with not making rules inside MQ special. Either something like forced-color-except like fantasai proposes, or could a priority on the declaration be an alternative?

[fantasai]

@tabatkins Uh, yeah. :) Fixed.

[css-meeting-bot]

The CSS Working Group just discussed [css-color-adjust-1] Cascade within forced-colors MQ.

The full IRC log of that discussion

<dael> Topic: [css-color-adjust-1] Cascade within forced-colors MQ
<dael> github: https://github.com//issues/4178
<dael> Rossen_: Is fantasai on?
<dael> Rossen_: I'll introduce.
<dael> Rossen_: Brought up by some framework devs when starting to adopt new forced colors MQ and forced colors adjust properties
<dael> Rossen_: Feedback is in contrast to previous impl in IE and Edge when used high-contrast and high-contrast-adjust the MQ and the way properties inside MQ evaluate is sign different
<dael> Rossen_: Boils down to it's currently...ergonomocs are such that if you decide to adjust a single color properties inside a forced color MQ you have to take over entire styling of elements
<dael> astearns: Because the forced color wins of MQ declaration?
<dael> Rossen_: NO. Current way to do it is you have to set foced color adjust to none inside the selector in the MQ. Once selected yoru lemeents, set it to none. Means you're taking the entire element and its subtree from forced color being applied
<dael> astearns: Why need to say none?
<dael> Rossen_: To change border color for ex
<dael> astearns: B/c forced color will otherwise override?
<dael> Rossen_: Correct.
<dael> Rossen_: We have a MQ that detects forced color adjust. Just like in example. When forced colors evaluates active inside MQ you do whatever you want. In this case select disabled = true elements. Wants to set the color of those to gray
<dael> Rossen_: To do this today you have to set forced-color adjust to none. Otherwise color would be window color
<dael> Rossen_: Making sense?
<dael> astearns: Yes
<dael> Rossen_: Previous to that high contrast impl we had we allowed individual prop to apply to individual elements. Color for that one property would override.
<heycam> q+
<dael> Rossen_: That's the proposal of this change when it started. Since there was discussion between AmeliaBR emilio and fantasai.
<dael> Rossen_: fantasai prop which I want to understand better is to do it other way around. Spec properties except ones you want to adjust. So forced colors except in this case border-stroke
<dael> Rossen_: Some support to this, but not seeing it recorded
<astearns> ack dbaron
<dael> astearns: Not sure anyone is agreeing with fantasai prop except something like it need to happen
<chrishtr> q+
<dael> dbaron: Was going to say I think a way to frame this is what we want is more granular way to override forced colors. A property that's everything or nothing isn't granular enough. Peopl care about properties or maybe declarations. Maybe makes sense to re-title issue?
<dael> dbaron: I think there's a 3rd option, complex, but have it in value of prop rather than sep prop. In hindsight when we have a property that modifies how another works we end up regretting. I think this is like box sizing in that way. But that's a lot of syntaxes to modify. Not sure if there's a more elegent way to do it.
<astearns> ack heycam
<dael> heycam: I wanted to agree with emilio initial comment finding it confusing if we change depending on what properties are inside. In favor of some opption that makes it more explicit be that fantasai prop or something like dbaron
<TabAtkins> q+
<dael> heycam: Question on MQ itself. Does it respond to value of [missed]> Forced color property determines if MQ matches?
<dael> chrishtr: I believe prop is not MQ but another property or value that overrides instead.
<TabAtkins> So a possible "adjust the value" option is to finally jump into using new ! options. Like `!override-forced-color`, so that *if* this declaration wins the cascade, it's allowed to override a forced color.
<dael> astearns: It's an alternative we're discussing but so far no one on thread has liked prop to having MQ allow override
<dael> heycam: Question is what determines if the MQ matches. Is it the property that enables forced color adjusting on a subtree?
<dael> Rossen_: Request is to enable single properties on selected items to take precedence over forced color
<astearns> q?
<dael> Rossen_: Target BG color which is set to canvas. If you select a given element within forced color acive MQ we would have allowd bg color to take precedence over forced color.
<TabAtkins> Then we switch forced-colors mode to, rather than using the cascade and UA-!important rules, instead just use magic to win the cascade automatically, *unless* the cascade-winning declaration has the appropriate ! on it.
<dael> Rossen_: Now to do it you have to first set foced-color-adust to none and take over everything by your self
<dael> heycam: Property to turn it to none would that make MQ not match?
<dael> Rossen_: NOt really. Mode of browser is still active
<dael> heycam: MQ is the overall mode, not individual sub trees where you set htat property
<dael> Rossen_: Yeah
<dael> heycam: Cool.
<TabAtkins> (And because we're using magic, this allows us to handle multiple such override modes in the future, if we introduce them, by internally handling conflicts, rather than trying to rely on the cascade to resolve them.)
<dael> astearns: Anything else heycam ?
<astearns> ack chrishtr
<dael> heycam: No
<dael> chrishtr: When you enforce colors mode I think there is no defined spec for what UA does. Right?
<dael> Rossen_: Not correct. Spec defining this is css-color-adjustment
<dael> chrishtr: Spells out exact stylesheets applied?
<astearns> https://www.w3.org/TR/css-color-adjust-1/#forced
<Rossen_> https://drafts.csswg.org/css-color-adjust-1/#forced-color-adjust-prop
<dael> Rossen_: We have the exact stylsheet? Asking if we define UA stylesheet?
<dael> Rossen_: No, we define colors are reverted to system colors. System colors are defined in Colors module
<dael> chrishtr: Different than heuristic darkening of page
<dael> Rossen_: Yes
<dbaron> https://drafts.csswg.org/css-color-adjust-1/#forced-colors-properties is somewhat well-defined, I think
<dael> chrishtr: Any override is predictable to dev
<dael> Rossen_: Yep
<dael> chrishtr: Got it, thank you
<astearns> ack TabAtkins
<dael> TabAtkins: I wrote stuff in IRC.
<dael> TabAtkins: Revisiting dbaron about building funcitonality into property value space. We do have a spot to do that in syntax with guar compat. Using stuff after ! which we only use for one thing. Syntax spec allows for more
<dael> TabAtkins: Possible way to address particular properties overriding forced color and to simplify is first switch forced color to magically win cascade regardless of author. THen allow author spec after a ! they override forced color. Say it's explicitly meant even if forced. If it wins cascade it doesn't get overwritten
<dael> TabAtkins: Same as figuring out how to insert a new keyword but allows completely consistant regardless of value space. Auto-extensible to future things. As well having forced colors apply magically gives more flexibility if we have to add more things like this
<florian> q?
<florian> q+
<dael> TabAtkins: THen can have resolution rules based on whatever arbitratry requirements we need. Without having to worry about cascade we let ! and author cascade determine
<dael> Rossen_: Question. Your prop is !override after property?
<dael> TabAtkins: Yeah
<dael> Rossen_: Like it. Pretty cool
<dael> TabAtkins: ! value space is allowed multi value so you can do !important override so we're not limiting authors
<dael> astearns: Talking about a generic ! override or !over-forced-colors
<dael> TabAtkins: More specific one
<dael> florian: On one hand what TabAtkins desc makes snese for this and has future extensibility. Does feel a lot like additional cascade origins. Not long ago had prop from miriam about having control over these things. I wonder if we shouldn't try harder to figure out that story. Various levels of cascade origin feels like what we're doing here. Worth exploring before being sure that's not it
<Rossen_> ack florian
<dael> TabAtkins: DOn't believe it's similar. While UA provided forced colors live on a high cascade, cascade-origins doesn't allow selective override unless we allow opt into even higher cascade. I like my proposal b/c doesn't have author cascade finnagle. They have existing rules and if they happen to be rules that should apply even in case of forced colors you add an indicator vs having a different cascade that auto-wins over another cascade that auto-wins
<dael> TabAtkins: You have one instance auto-winning all the time in that case and that may not be what you want
<dael> miriam: Agree with TabAtkins. Feels different use case. I'd be willing to dig in further to see if overlap but offhand seems not same problem
<Rossen_> q?
<dael> astearns: Other opinions?
<Rossen_> ack dbaron
<dael> dbaron: Reference to custom cascade brought an interesting question. If an author has rules they want to override forced colors and other rules that would normally override them what happens? Do we want that to be possible? Maybe one arg is if author says this overrides forced color it overrides all the other rules.
<dael> dbaron: Maybe want authors to do that. SOme of these have confusing outcomes. Might think someone wants it, but may be 1 person wants and 99 are confused. Makes me think maybe more like custom-cascade origins. Maybe this is a little more like cascade. Worth thinking about what we want to allow and what's too confusing
<dael> florian: I think we can do 3 things. One is you set super override and always wins. Another is super override doesn't win if you've overwritten it with the normal cascade. Asking for trouble b/c people won't test with forced colors
<dael> dbaron: 3 is horrible
<dael> TabAtkins: Writing down 1, 2, and 3 would be good
<dbaron> 1. color: blue ! override always beats color: red, even if red would normally win the cascade
<dael> florian: If you have blue in yoru normal cascade which wins then red !white with specificifity that doesn't win it's still blue. THe red lost alreay. That's 1
<dbaron> 2. color blue ! override and color: red cascade normally, and if red wins in the cascade, then there's no longer an override and the blue just gets ignored
<dael> florian: 2 is ! override makes red more important than forced color and more important than blue. Implicitly important
<dael> florian: 3 which is bad is if !override-red lioses to blue in normal and over blue and system in forced.
<dael> TabAtkins: Agree. 1st is per declaration. 2nd is mega-important. 3rd is bad
<dael> dbaron: I think first is mega important
<dael> TabAtkins: Do we want to take this with the two good options to the issue? Or decide now?
<dael> astearns: Rossen_?
<dbaron> Issue discussion, I thnik -- there's a ton of stuff to sort out here.
<dael> Rossen_: It's easy to discount option 3. Exploring 2 is interesting but i'm hesitant on mega-important.
<TabAtkins> I mean, !mega-important is just Custom Cascade Origins
<dbaron> This 1/2/3 thing is a discussion within a discussion.
<dael> Rossen_: If we can agree on 1 vs 2 that's a path forward to experiment and see how it works
<dael> dbaron: Feel like 1 vs 2 is a discussion in a discussion and there's large points to sort out. Better in the issue
<dael> astearns: Can resolve that we'll solve this issue in the value space
<dael> TabAtkins: As opposed to properties, yeah
<dael> dbaron: When I said value space I wouldn't have counted TabAtkins proposal as there, but I like TabAtkins proposal
<dael> Rossen_: I like it as well
<heycam> if there are many properties to override to adapt to the forced color mode I wonder if it will be onerous to write an !override on every property declaration
<dael> astearns: Let's take it back to the issue for now since we have alternatives and people like emilio and fremy with strong opinions. THen we can hopefully resolve soon.
<TabAtkins> (Given a time machine, I'd have proposed adding `!border-box` to the sizing properties, rather than box-sizing. ^_^)
<dael> astearns: Any last words?

[AmeliaBR]

The more I think of this, the more I like Fantasai's suggestion of explicitly listing the properties you want to ignore, as the values of a property which cascades normally.

Maybe make it forced-color-ignore: all | <property-name>+, where forced-color-ignore: all replaces the currently spec'd forced-color-adjust: none.

The one downside to this is that, like all properties that take a list of values (transition-property, will-change, etc.), you can't add values to that list by separate selectors, you need to set them all at once.

[tabatkins]

Summary of the discussion is that dbaron argued that we've historically considered "property A which influences how property B works" as a bad idea; a notable example is 'box-sizing' which is generally considered a legacy mistake. Several people agreed with this.

Instead, some sort of addition to the value space of the properties was preferred. I suggested that we finally use the ! space that Syntax allows, as it gives us an unambiguous way to add to flags to values without worrying about syntax collisions; this would look something like color: blue !override-forced-color;. (Post-call correction: I actually simplified Syntax to just look for !important at some point, and not have a general mechanism. But it's still totally possible to re-open that with some trivial fixes.) This wouldn't conflict with the existing !important; you should still be able to say color: blue !important override-forced-color; if you wanted to.

This received general approval, but there was a split in how it should be interpreted. The broadly accepted possibilities were:

1. The !-ident would kick the declaration into a mega-important cascade origin, overriding the UA-important origin that the forced-colors declarations live in. (This means that in .foo { color: red !override-forced-color; } #bar { color: blue; }, the red would win in all cases over the blue, despite blue having a higher specificity.)

2. The forced-colors-mode declarations, rather than living in a high origin, instead magically override the cascade winner. If the cascade winner has the !-ident, it doesn't get overridden. (So in the above example, the blue would win the cascade as normal, and then get overridden by a forced color.)

3. Like 1, but the declaration gets moved into the special origin only if forced colors are active. (So blue would win normally, but red would win if forced-colors-mode was active.)

Rossen didn't want to discard (3), but Florian and I didn't like it, because it would mean a significant behavior change in forced-colors-mode that is likely to not really be tested.

---

Also, given #4175 (comment), forced colors mode can't be just literally applying rules in a high origin based on a MQ. It's gonna have to do something magical for at least some properties, to preserve the alpha component of the author's cascade-winning color, so it doesn't feel like there's much value in preserving the fiction that it's just a line in the UA sheet; instead I think we should go whole-hog in the "it's a magical adjustment" direction.

[astearns]

@emilio @FremyCompany @melanierichards please take a look at the above and weigh in

[AmeliaBR]

OK, building on Tab's three options for interpreting a !override-forced-colors, one thing to think about is how they interact with the media query:

• In (1), if you used the override outside of a (forced-colors: active) media query, it would behave as a !super-important when the browser isn't in forced colors mode.

  This seems like a potential for misuse, throw it on when you need to override a 3rd-party library's !important style, without testing for what it actually does in forced color mode.

• In (3), the media query would become completely optional unless you also wanted to adjust other properties, as the !override-f-c would act as a declaration-scoped media query condition itself.

  E.g., the following would always have a red border, but the text color would be purple in normal mode (because of regular positional cascade) and the highlightText color in forced color mode (because of forced color mode triggering the super important behavior):

  .selector {
    border: thick solid red !override-forced-colors;
    color: highlightText !override-forced-colors;
    color: purple;
  }

• In (2), the media query would be optional if you wanted to force your normal style to stay the same in forced-color mode, but it would be required if you want to define your own color overrides. Which seems like a nice compromise to me.

  The previous example would become:

  .selector {
    border: thick solid red !override-forced-colors;
    color: purple;
  }
  @media (forced-colors: active) {
    .selector {
      color: highlightText !override-forced-colors;
    }
  }

  The only downside is one that is shared with all media queries: the MQ doesn't add any specificity or importance to the declaration, so authors still need to make sure that the MQ rules override the basic rules when the MQ is active.

In all of these cases, if you do use the media query, you'd probably need a big long line of !override-f-c modifiers on every declaration inside the MQ block.

In contrast, the way the original -ms- prefixed media query worked is that by the nature of being contained inside that MQ block, declarations had special importance given to them. I'm not sure of how that special importance worked in its interactions with the rest of the cascade, but it's worth considering whether it would be possible to recreate some of that simplicity.

Maybe a media query that is activated by forced colors mode could implicitly get the !override-f-c behavior for all of its declarations. Or maybe there could be a new syntax way of setting a ! modifier on a media query block as a whole.

Edit: This reads as if I'm all for Tab's option (2). I want to clarify that I think it's the best of those 3 options, but I'm still not fully convinced that a ! modifier is the best way to go.

[fantasai]

I don't like the proposal.

Wrt #1, “overriding the UA-important origin that the forced-colors“, that's not actually how the mechanism works, because we resolved in #4020 to rewrite the author rules instead.

Wrt all of them, they violate the principle that the UA !important rules always win. Always. And user !important rules override author rules. Always. Author rules should not be moving outside their cascade origin.

[tabatkins]

Wrt all of them, they violate the principle that the UA !important rules always win. Always. And user !important rules override author rules. Always. Author rules should not be moving outside their cascade origin.

I'm confused why you're implying this is true for "all of them" - one of the solutions is just "normal cascade, and if the cascade-winner has !foo, it doesn't get overridden by forced-colors".

The other ones do talk about a new higher origin, but I assume it's still meant to be an author-level origin, and thus will get overridden by UA and user !important things.

[FremyCompany]

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. The premise is that 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 on them 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. I'd posit this is useful even if authors specified forced-colors-adjust: none on a paragraph, not just auto GrayText Canvas)

This second proposal is more strict than the first one, but slightly 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)

[FremyCompany]

Option 1 addendum: color(..., system-color)
Last but not least, I would like to note that with a tiny update to color() behavior (no syntax change needed), we can make the life of developers super easy!

The proposed change here would be that, in forced-colors mode, if the fallback color of the color() function is a system color, this system color is always returned irrespective of whether the colors specified on the left would otherwise be recognized as valid.

With this addition, developers don't need to write this:

.disabled-button {
    color: rgb(128 128 128);
}
@media(forced-colors: active) {
    .disabled-button {
        border-color: GrayText;
        forced-color-adjust: out-of-palette-only;
    }
}

They could write this instead: (and abstract this in a custom property variable if frequent)

.disabled-button { 
    color: color(rgb 128 128 128, GrayText); 
    forced-color-adjust: out-of-palette-only;
}

[tabatkins]

Okay, so on review, @fantasai and I like the "out of palette only" suggestion the best here. It seems to hit the use-case well while still respecting forced colors as much as possible. In fact, we think this should be the "auto" behavior; if we do still want the original auto behavior (do we?) we can add this as a stricter keyword.

François' idea about auto-triggering color() fallback to a system color if possible is also pretty good, we think. Essentially, in forced-color mode we pretend that all the colorspaces aren't loaded, except for one capable of expressing the dozen-ish system colors.

[css-meeting-bot]

The CSS Working Group just discussed [css-color-adjust-1] more granular overriding of forced colors mode than per-element.

The full IRC log of that discussion

<dael> Topic: [css-color-adjust-1] more granular overriding of forced colors mode than per-element
<argyle> let's get this party started! woooooooOOOOOOOOOO
<dael> github: https://github.com//issues/4178
<dael> TabAtkins: Had a bunch of discussions. In certain cases authors might want to override forced colors. Hopefully for useful purposes such as when forced colors removes nec/ distinctions.
<dael> TabAtkins: Lots of discussion in thread and talk on F2F.
<dael> TabAtkins: fremy came up with an idea I and fantasai like. If people use system colors already just don't adjust them.
<dael> TabAtkins: If people use own random brand colors we overwrite. If system colors used don't override even if forced color would use different system colors.
<dael> TabAtkins: That way people can work in palette of system color but direct how it looks when precision is necessary
<dael> TabAtkins: Color function also has a fallback mech if your color space is not loaded or out of gamut.
<dael> TabAtkins: Should consider all color spaces unloaded in forced colors. This let syou in non forced colors paint but auto say what fallback should be to system so you dn't have to design with system colors from the get go, but rely on them when necessary
<florian> I like it. Well done fremy.
<dael> TabAtkins: When doing forced color leave system colors as is regardless of system color. I think that solves it without all the complication in past
<dael> Rossen_: If I have a selector that's intending to change color of border-left to non-system and forced color MQ matches how would that work? @media forced-colors and match prefers-color-scheme:dark so I want to give left-border my dark blue color. how would it work?
<dael> TabAtkins: It would not.
<dael> Rossen_: That's the pirmary use case. That's why we went down !override path. If people are using system colors that's a no opt. If I said canvas fine. I can fix from a system but not my own.
<dael> TabAtkins: It's not a no op because you can choose a color that's not forced color. You can invoke marked color for example. But you can't choose arbitrary color
<dael> Rossen_: I think that's main motivational case
<dael> TabAtkins: It wasn't clear in thread arbitrary color was required. In that case let's shelve this because hte suggestion is not possible.
<fantasai> That was not in any of the examples that melanierichards raised
<dael> Rossen_: Sorry it wasn't clear in thread, example could be clearer. Fine to move on. Thank you for introducing it.
<dael> astearns: Let's make sure that example is encoded in a recent comment. We'll likely come back

[atanassov]

Perhaps the motivational test case mislead the direction of this issue a bit. The main use case for the capability is intended to allow authors to supply arbitrary color values for a specific property override.

Consider the following use case where the author's intent is to change the text color to dark gray in the case of forced-colors:black-white

@media (forced-colors: active) {
   @media (prefers-color-scheme: dark) {
      [aria-disabled="true"] {
         color: #767676;
      }
   }
}

Per our previous discussions my understanding was that our intent is to enable this by adding the !forced-override (name tbd of course) to any selector. That same example is then enabled as follows

 @media (prefers-color-scheme: dark) {
    [aria-disabled="true"] {
       color: #767676 !foced-override;
    }
 }

[tabatkins]

I suppose my question now is: why is this different from the example in the OP? What is the justification for using colors other than what the user explicitly indicated they want to exclusively see?

Note in particular that forced-colors gives zero indication of what those colors are; all the author knows is that the page will be shifted into exclusively using the system colors. (And possibly that it's roughly a darkish or lightish theme.)

In particular, there is no guarantee in your example that #767676 isn't already the text or background color (or close to it), rendering the text either invisible or indistinguishable from normal. Or even if neither of these are true, the other disabled text on the platform is probably not in #767676, so this'll look different for no apparent reason. Whereas using graytext would make it look exactly like all the other disabled text on the platform automatically, whatever color that was.

I'd like to see some examples that need a specific color and couldn't be served by a system color.

[alisonmaher]

@tabatkins I combed through the list of bugs reported in Microsoft Edge that are related to this issue, and the majority could be resolved by the most recent proposal (ie. don't override system color in forced colors mode).

There were a few example sites that I came across that would require specific colors other than system colors.

1. Bing Maps, for example, requires non-system colors to ensure the map is still readable in forced colors mode. However, because the entire map is being adjusted by the author, forced-color-adjust: none already works great in this case.
2. The map on the right of this Wikipedia article has a legend that becomes unreadable in forced colors mode. In this case, using system colors would be insufficient.
3. Color options for products (ex. choosing a color for a laptop) can become unusable in forced colors mode and would require non-system colors.

Although these examples would require non-system colors to maintain usability, I could easily see applying forced-color-adjust: none as a resolution in these specific cases. Perhaps @atanassov knows of additional examples, though, where this wouldn't be the case?

[fantasai]

Pushed a revision of your edits, @tabatkins. There remain some interesting questions:

• Is the result of forcing a computed or used value? Mapping out-of-gamut colors is a used-value time operation, which I thought is what we were doing here, but your edits indicate changes to the computed value.
• Previous text reverted colors to match the UA+user style sheets. I've restored this requirement as a SHOULD, but that's also up for discussion.
• These rules will override any explicit values in the UA or user style sheet. Are we sure that's what we want?

[css-meeting-bot]

The CSS Working Group just discussed [css-color-adjust-1] more granular overriding of forced colors mode than per-element, and agreed to the following:

• RESOLVED: Republish WD with the edits

The full IRC log of that discussion

<emilio> topic: [css-color-adjust-1] more granular overriding of forced colors mode than per-element
<astearns> particularly https://github.com//issues/4178#issuecomment-700481333
<fantasai> github: https://github.com//issues/4178#issuecomment-700481333
<emilio> fantasai: I had a few follow-up questions, one of them we just resolved on
<emilio> ... we said that reverted colors should try to match the user stylesheet
<emilio> ... I added that as a SHOULD
<emilio> ... This would override explicit UA/User values, is that what we want?
<fantasai> https://github.com/w3c/csswg-drafts/commit/588ce6183bc25e62b61ec723f700b2c356d8a89a#diff-8974d243f99b24bfbefbf89dee6dc5d4a06890610cb205535e0d8d279db1d587
<emilio> TabAtkins: third bullet point in ^ is the relevant one
<emilio> ... before we had no details other than it should be an "appropriate" system color
<emilio> fremy: yeah I assume it'd be the one in the UA sheet by default
<emilio> ... as an author you can override it using system colors
<emilio> TabAtkins: are we looking for a resolution or just review?
<emilio> fantasai: Yeah I wanted to check those requirements and whether SHOULD is appropriate
<emilio> RESOLVED: Republish WD with the edits
<emilio> fantasai: we don't have that many issues left in color-adjust
<emilio> ... I think the other major issue is `only`