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