[css-color-adjust-1] background-color in forced color modes needs more than a simple unset

[melanierichards]

In Properties Affected by Forced Colors Mode we define a set of UA stylesheet expectations for various properties, including:

background-color: revert !important;

In practice, this means most elements are unset to a transparent background color, which is not precisely the best user experience. For example, as the spec is currently written, .foo in this fiddle would have a transparent background and would be awkward to modify via UA stylesheet on top of an unset/revert.

Instead, we probably want to manage the forced background-color post computed-value resolution, such that:

• Elements with non-transparent computed background colors are rendered with a solid system background color (e.g. .foo in the example renders with a background color of Canvas)
• Otherwise, elements' background-color can be unset as described. The UA is then free to make further adjustments in their stylesheet, using simple selectors (e.g. selecting for <button> elements).

The spec probably needs a language update if allowing this UA logic seems reasonable.

[atanassov]

One more clarification in case it is needed. The intended behavior is for background-color'only, background-image are unaffected. The intended contrast ratios in these cases is achieved through the use of backplate.

[fantasai]

Another question: define “non-transparent”? :) Is it only rgba(0,0,0,0) or also other fully-transparent colors?

(It would be really nice if transparent computed to itself here, so we could run the check against the keyword and not one edge of a continuous scale.)

[melanierichards]

Good question, I was considering "transparent" to mean "any color whose alpha channel computes to 0". So both of these should be unset based on computed value, as opposed to rendered with a system background color: https://jsfiddle.net/pn7sjc2h/2/

[css-meeting-bot]

The CSS Working Group just discussed background-color in forced color modes needs more than a simple unset, and agreed to the following:

• RESOLVED: background-color computes to the system background-color for all values but heh alpha channel

The full IRC log of that discussion

<dael> Topic: background-color in forced color modes needs more than a simple unset
<dael> github: https://github.com//issues/4175
<dael> Rossen_: I'll take it since melanierichards is on vacation
<dael> astearns: How much time do you need?
<dael> Rossen_: Quick.
<Rossen_> https://www.w3.org/TR/css-color-adjust-1/#forced-colors-properties
<dael> Rossen_: When the forced color behavior was desc in the link^
<dael> Rossen_: These are the properties overwritten by system colors. Fallback was spec that every property that has no overrides gets the revert !important which means revert to original UA stylehseet which for bg color is transparent
<dael> Rossen_: Not expected. All other colors reverting makes sense. Background being reverted to ransparent you lose all non-transparent. Intended it go to system bg color
<dael> Rossen_: Idea from fantasai was can re do something to transparent color and see if computes to self similar to currentColor. Not really the same. Transparent color is a named color.
<aja> re: forced-colors, should transparent (borders-color only?) be allowed in addition to the non-deprecated system colors? will file issue if it sounds reasonable.
<dael> Rossen_: If we spec transparent computes to itself as computed we're making an exception for one named color. Think it's a bit wierd. crrentColor is an instruction to cascade algo to go back to a value. Not really the same
<dael> Rossen_: Ask here is that we take bg color out of the list and spec the behavior that it falls back to system bg color in case of forced colors
<dael> Rossen_: That was intended impl that we had to back out when making code according to spec
<dael> AmeliaBR: This would need to be defined in prose b/c incvolves a switch on computed value we can't define in cascade.
<dael> Rossen_: Yes
<dael> AmeliaBR: Would it work to force all bg to be opaque?
<dael> Rossen_: Inverse problem which would be jsut as bad
<dael> AmeliaBR: Okay.
<dael> AmeliaBR: It really has to be done with a little magic ans special prose
<dael> Rossen_: Magic is simple. When you compute value of bg color for non-transparent the value is computed to the system bg color.
<dael> Rossen_: To your observation AmeliaBR the explanation will be bg color only.
<dael> AmeliaBR: Any interaction with bg image? bg image the current proposal is keep the image and use backplate behind text to add contrast. Would you do them separately?
<dael> Rossen_: What you said is right for bg image. For bg color if the color is non-transparent it will be system bg color. So if you draw a backplate it would be non-observable visually or object model. Somewhat wasteful to render.
<dael> Rossen_: Otherwise for bg image the backplate takes effect and guar. forground in desired contrast
<dael> dbaron: Is this the right treatment for bg colors with alpha between transparent and opaque. alternative is don't touch alpha and change color compontents to system color
<dael> Rossen_: valid point. There's a different issue that addresses what you desribed when talking about interpolation. It will end up interpolating most of alpha channel. I like your proposal
<dael> astearns: Summary Rossen_ ?
<dael> Rossen_: Prop: background-color computes to the system background-color for all values but hte alpha channel
<dael> astearns: Can we resolve on this?
<dael> astearns: Objections?
<dael> RESOLVED: background-color computes to the system background-color for all values but heh alpha channel
<dael> s/heh/the

[fantasai]

OK, I edited this in cffce20

I ran into a complication: not all elements are supposed to be forced to CanvasText. It wasn't clear from the discussion what to do here, so I specified that if the UA stylesheet has no background-color rule, then we do the force-channels-other-than-alpha rule, but if it does, we simply revert the author level.

Marking Agenda+ to discuss whether that's what we want, or we want something else.

[css-meeting-bot]

The CSS Working Group just discussed [css-color-adjust-1] background-color in forced color modes needs more than a simple unset.

The full IRC log of that discussion

<dael> Topic: [css-color-adjust-1] background-color in forced color modes needs more than a simple unset
<dael> github: https://github.com//issues/4175
<dael> Rossen_: I think fantasai has this one to resolve on the edits I suppose
<dael> astearns: lajava put this on the agenda
<dael> astearns: Wait, wrong link
<fantasai> https://github.com//issues/4175#issuecomment-595582638
<dael> astearns: Yes, last comment is fantasai going over actual edits.
<dael> fantasai: We were talking about forcing the colors other than alpha channel to be canvas text but we don't use canvas for every item. Example input element.
<fantasai> https://github.com/w3c/csswg-drafts/commit/cffce2008ce030f4b098aece82b95c109485594f
<dael> fantasai: I wasn't clear on that case. I spec UA stylesheet has no bg color rule then we force everything to canvas text. If it does have a rule then we revert hte author setting away. Edits here ^
<dael> fantasai: I wanted to check b/c it's a weird case but I didn't know what else to do that would work
<dael> AmeliaBR: There are 2 things we need to factor in
<dael> AmeliaBR: One is if the custom layout and stylesheet of the website is designed with overlapping content that requires opaque we need to keep that. If transparent keep that
<dael> AmeliaBR: Other is bg color in forced color have particular pairs. Regular canvas and text for main, buttons and inputs have other pairs
<dael> AmeliaBR: I'm not sure whether this would fix both those cases. BUt those are the two trying to address
<dael> fantasai: If you want to do this 100% right for most elements you force to canvas but elemnts inside button you fore to button bg. But that's really tricky, esp because buttons don't have much in them
<dael> Rossen_: What you desc sounds concerning. We can't be dependant on composition or layout while deciding computed value
<dael> fantasai: Right
<fantasai> s/, esp/. But/
<dael> Rossen_: Which is how I heard you desc
<fantasai> s/in them/in them, decided not to worry about that complication/
<dael> AmeliaBR: I wasn't suggesting browser look at layout. Suggesting browser respect if author styles have opaque background. Important b/c overlapping content
<dael> fantasai: What I didn't want to do...what we could do...what is in the rule handles that for everything except things like buttons. Force all channels other than alpha. For buttons and input fields I didn't put that b/c seemed harder to calc what's going one. Easier to revert in those cases. B/c don't have complext things if button is semi-transparent no it's opaque
<dael> AmeliaBR: Where rule will fail is element inside a button where for whatever reason it's expected to be opaque but the UA stylehseet won't have a rule for a SVG inside a button, just a rule for the button. As written that case would ge canvas bg which wouldn't be appropriate b/c foreground for the span is the buttons
<jensimmons> present-
<dael> AmeliaBR: Instead of making the switch based on if there's a UA rule could we make this a special bg color being a special keyword that means find opposite of foreground using sytem color pairs? We have defined pairs in system colors, opposite of button-text is button-face. If we could define that tbe bg color in these cases is based on look up current color and calc proper bg from that
<dael> fantasai: Only works b/c reverting color right?
<dael> AmeliaBR: Right, after revert so color gets forced color for text of that element
<dael> Rossen_: Perhaps this is desc different forced color scenario then one for windows? Not sure how foreground color is differnt from text
<dael> fantasai: First go through an do revert rules. As result you've reverted color so doc is canvas-text and button is button-text. That's done and colors have inherited through. Span inside a button is also button-text.
<dael> fantasai: Now try and figure out bg. bg says we'll take colors spec and set all non-alpha channels to be the color that is the bg associated with the current color. If we're in the doc in a span we say what's the color and color says I am canvas-text and so pairing is canvas and we force to canvas color
<dael> fantasai: Button says it's button-text to background color forces to button-color.
<emilio> (sorry, forgot about timezones)
<dael> fantasai: AmeliaBR is doing a interesting cheat b/c color is inherited which color you force to needs to be inherited. b/c color is inherited taking advantage of that.
<dael> Rossen_: Thank you for explaining.
<dael> Rossen_: Is this desc a different feature, though? On windows sets both bg and foreground. So can only have colors choosen by user
<dael> fantasai: Yes, that's what happens but doing color calc first and then do background based on that
<dael> Rossen_: But bg color is also provided why need to compute?
<dael> fantasai: Element inside a button. Span in a button what bg do you use?
<dael> dbaron: One other concern with what I think prop is is while good practice is to set on same lemenet, might in reality set colors on a decendant of background. Even though color inherits setting the backgorund might not be reliable
<dael> AmeliaBR: SHould be effected by general color property reverting rules.
<dael> AmeliaBR: To address Rossen_ concern is the difference between this and MS browsers is wanting to support the situation of elements in userstylesheet that have opaque but don't have opaque in UA. That's where complication comes from. Pop up that's outside borders of button or custom inputs that do something a little different then UA stylesheet and you need an opaque bg browser needs to know what opaque bg to give that element
<dael> fantasai: I think the concerns is elements in author stylesheet with opaque
<dael> AmeliaBR: Yes, sorry
<dael> fantasai: Back to beginning. Base set of rules is instead of reverting bg we wanted to address elements that have an opaque bg in author and you want to make sure everything is right in forced color. Decided to have all bg match canvas but keep alpha channel. THat doesn't work for things like button or input. So we needed to do something for those since can't force to canvas-text
<dael> fantasai: One prop is UA needs to know what's not canvas bg and force those to what supposed to be. In button it forces to button bg. Input tp field bg.
<dael> fantasai: Problem with this is that if you have element inside the button that has a bg that element isn't registered in UA stylehseet as special bg and forced to canvas. Might not be right when it's on a button. B/c it's opaque we change to canvas which is white and then we have a button with a white backgrond so it's white text on white button and unreadable. THat's what AmeliaBR tries to fix
<dael> emilio: Looks like FF. For color and bg we have revert and if nothing reverts we set to [missed]. DOn't preserve alpha but could
<AmeliaBR> s/[missed]/initial/
<dael> fantasai: What I put in spec is assumption that opaque in buttons is not a thing we want to worry about. For elements with bg in UA stylesheet UA knows that and reverts and doens't modify alpha channel. We could decide we don't want to solve the problem or we can use AmeliaBR trick
<dael> AmeliaBR: Would people feel better if we wrote text and came back?
<dael> astearns: I was about to suggest that. I think it's getting a bit circular. SOunds like not talking about reverting but an additional trick
<dael> AmeliaBR: Changing fantasai edits from a week ago
<dael> astearns: Modify, not revert
<dael> fantasai: Changing mech to get behavior
<dael> astearns: Let's go back to issue. AmeliaBR you can write up your alternative text and we can come back on another call after people can take a look and then we can decide if we want to change
<fantasai> s/Changing mech/Doesn't change behavior of base cases, but changes mechanism/
<dael> chrishtr: May I ask for examples?
<dael> AmeliaBR: Sounds very good