Re: [csswg-drafts] [css-color-6] color-contrast() should take transparency into account (#7358)

The CSS Working Group just discussed `[css-color-6] color-contrast() should take transparency into account`.

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> lea: We've discussed before. Right now contrast-color() ignores transparency entirely, pretends the colors are opaque.<br>
&lt;TabAtkins> lea: This can produce wildly wrong results.<br>
&lt;TabAtkins> lea: A color with a very low alpha but otherwise has a good contrast, the algo can choose that over an opaque color that would *actually* contrast better<br>
&lt;TabAtkins> lea: Previously we resolved that you composite a semi-transparent fg against the bg, but we didn't resolve on what to composite the bg against<br>
&lt;TabAtkins> lea: There are three options<br>
&lt;TabAtkins> lea: (1) the opaque version fo the fg<br>
&lt;TabAtkins> lea: (2) opaque white or balck, whichever is better<br>
&lt;TabAtkins> lea: (3) canvas color<br>
&lt;TabAtkins> lea: Or a UA-specified color.<br>
&lt;TabAtkins> lea: So we ahve to resolve on the color and we'll have a complete algo<br>
&lt;fantasai> s/Or a UA-specified color/(4) Color picked by UA to minimize the contrast (per contrast algo specified)<br>
&lt;TabAtkins> lea: Whatever heuristic we pick it might be wrong, so it might also be useful in a later version to add a color-over() that specifies the compositing...<br>
&lt;argyle> q+<br>
&lt;TabAtkins> TabAtkins: Weak preference for canvas color<br>
&lt;TabAtkins> chris: Me too, seems canvas color is a good default, takes light/dark mode into account<br>
&lt;TabAtkins> fantasai: Seems like it could be wronger than fg<br>
&lt;TabAtkins> chris: fg is gonna be the worst possible<br>
&lt;TabAtkins> fantasai: color could be in a subtree with a different color than canvas<br>
&lt;astearns> ack argyle<br>
&lt;TabAtkins> dbaron: I think it's posible to come up with an algorithm for "worst possible color" but not sure it's any of these<br>
&lt;fantasai> fantasai^: fg is not always worst possible, depends on the composited background<br>
&lt;TabAtkins> argyle: I'm remdined of accent color - we compute it against canvas color<br>
&lt;TabAtkins> argyle: I think it would be nice to have a fallback mechanism where it falls back to canvas if there's not an html or body color<br>
&lt;TabAtkins> argyle: So it could crawl up and try to find a solid color, otherwise use the UA canvas<br>
&lt;smfr> q+<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> fantasai: I don't think we can look for the actual bg - frequently you're rendering over an image<br>
&lt;TabAtkins> fantasai: and we want to do this locally without having to do layout or crawl the tree<br>
&lt;TabAtkins> fantasai: so i think we need an answer locally based on infromation on the element itself<br>
&lt;astearns> ack smfr<br>
&lt;TabAtkins> smfr: I think we're assumign that contrast is used on the fg of an element.<br>
&lt;TabAtkins> smfr: But might want to use it for the bg - seems like we're biasing<br>
&lt;argyle> i just used color-contrast() on the bg in this demo https://nerdy.dev/color-from-color-contrast-result<br>
&lt;TabAtkins> chris: We're actually not doing that - we're explicit about whether the color is a fg or bg<br>
&lt;TabAtkins> chris: So this is only an issue where it's the bg color that's partially transparent<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> fantasai: I think i'd prefer we went with opacified fg, or "UA-chosen worst possible color"<br>
&lt;argyle> q+<br>
&lt;TabAtkins> fantasai: We're trying to find a color that passes a threshold for some contrast<br>
&lt;astearns> ack argyle<br>
&lt;TabAtkins> argyle: What if we added an option for users to specify it?<br>
&lt;chris> color picked by the UA sounds handwavy, difficult to test, non-interoperable<br>
&lt;chris> q+<br>
&lt;TabAtkins> argyle: Like it defautls to canvas, but as an author I know what color it's gonna be against<br>
&lt;fantasai> chris, it's "color picked by the UA to minimize contrast per the contrast algo used"<br>
&lt;TabAtkins> argyle: So authors can add intelligence but we still have a reasonable default<br>
&lt;fantasai> which is not so vague<br>
&lt;astearns> ack chris<br>
&lt;TabAtkins> chris: I see what Adam's suggesting, but I think putting the same color in twice means you ahve to update it twice and keep in sync<br>
&lt;TabAtkins> argyle: Custom props is your way out of that - already this algo is loaded with inputs that need copy/paste or custom props<br>
&lt;TabAtkins> lea: Even using the custom prop is some repetition<br>
&lt;dbaron> Seems like what Adam's suggesting could also be done with a composite(A over B) color function or similar rather than additional syntax for the contrast function.<br>
&lt;TabAtkins> lea: Remembering which of the custom colors you're using<br>
&lt;TabAtkins> lea: Does seem nice as optional, but shouldn't be only way<br>
&lt;TabAtkins> astearns: We're over time, and I'm not hearing consensus, so let's take back to issue<br>
</details>


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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 8 February 2023 18:02:36 UTC