Re: [csswg-drafts] [css-color-adjust-1] background-color in forced color modes needs more than a simple unset (#4175)

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

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic:  [css-color-adjust-1] background-color in forced color modes needs more than a simple unset<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/4175<br>
&lt;dael> Rossen_: I think fantasai has this one to resolve on the edits I suppose<br>
&lt;dael> astearns: lajava put this on the agenda<br>
&lt;dael> astearns: Wait, wrong link<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/issues/4175#issuecomment-595582638<br>
&lt;dael> astearns: Yes, last comment is fantasai going over actual edits.<br>
&lt;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.<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/commit/cffce2008ce030f4b098aece82b95c109485594f<br>
&lt;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 ^<br>
&lt;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<br>
&lt;dael> AmeliaBR: There are 2 things we need to factor in<br>
&lt;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<br>
&lt;dael> AmeliaBR: Other is bg color in forced color have particular pairs. Regular canvas and text for main, buttons and inputs have other pairs<br>
&lt;dael> AmeliaBR: I'm not sure whether this would fix both those cases. BUt those are the two trying to address<br>
&lt;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<br>
&lt;dael> Rossen_: What you desc sounds concerning. We can't be dependant on composition or layout while deciding computed value<br>
&lt;dael> fantasai: Right<br>
&lt;fantasai> s/, esp/. But/<br>
&lt;dael> Rossen_: Which is how I heard you desc<br>
&lt;fantasai> s/in them/in them, decided not to worry about that complication/<br>
&lt;dael> AmeliaBR: I wasn't suggesting browser look at layout. Suggesting browser respect if author styles have opaque background. Important b/c overlapping content<br>
&lt;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<br>
&lt;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<br>
&lt;jensimmons> present-<br>
&lt;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<br>
&lt;dael> fantasai: Only works b/c reverting color right?<br>
&lt;dael> AmeliaBR: Right, after revert so color gets forced color for text of that element<br>
&lt;dael> Rossen_: Perhaps this is desc different forced color scenario then one for windows? Not sure how foreground color is differnt from text<br>
&lt;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.<br>
&lt;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<br>
&lt;dael> fantasai: Button says it's button-text to background color forces to button-color.<br>
&lt;emilio> (sorry, forgot about timezones)<br>
&lt;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.<br>
&lt;dael> Rossen_: Thank you for explaining.<br>
&lt;dael> Rossen_: Is this desc a different feature, though? On windows sets both bg and foreground. So can only have colors choosen by user<br>
&lt;dael> fantasai: Yes, that's what happens but doing color calc first and then do background based on that<br>
&lt;dael> Rossen_: But bg color is also provided why need to compute?<br>
&lt;dael> fantasai: Element inside a button. Span in a button what bg do you use?<br>
&lt;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<br>
&lt;dael> AmeliaBR: SHould be effected by general color property reverting rules.<br>
&lt;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<br>
&lt;dael> fantasai: I think the concerns is elements in author stylesheet with opaque<br>
&lt;dael> AmeliaBR: Yes, sorry<br>
&lt;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<br>
&lt;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.<br>
&lt;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<br>
&lt;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<br>
&lt;AmeliaBR> s/[missed]/initial/<br>
&lt;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<br>
&lt;dael> AmeliaBR: Would people feel better if we wrote text and came back?<br>
&lt;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<br>
&lt;dael> AmeliaBR: Changing fantasai edits from a week ago<br>
&lt;dael> astearns: Modify, not revert<br>
&lt;dael> fantasai: Changing mech to get behavior<br>
&lt;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<br>
&lt;fantasai> s/Changing mech/Doesn't change behavior of base cases, but changes mechanism/<br>
&lt;dael> chrishtr: May I ask for examples?<br>
&lt;dael> AmeliaBR: Sounds very good<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4175#issuecomment-600731176 using your GitHub account

Received on Wednesday, 18 March 2020 16:27:43 UTC