Re: [csswg-drafts] [css-color-adjust-1] Spec currently breaks use of currentColor for SVG icons in WHCM (#6310)

The CSS Working Group just discussed `Color Adjust`, and agreed to the following:

* `RESOLVED: Add new keyword to forced-color-adjust as described above, apply it in UA default stylesheet for SVG root element`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: Color Adjust<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/6310<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/issues/6310#issuecomment-858112357<br>
&lt;fremy> fantasai: the current proposal is not gonna get us in good shape in all cases<br>
&lt;fremy> fantasai: currently our resolution would not work if the svg has set its color explicitly<br>
&lt;fremy> fantasai: so my new proposal is that if the color is orginating from outside the svg then we recolor, but if not then we keep it<br>
&lt;fremy> fantasai: proposal is to add a new keyword for that magic behavior which depends on the origin of the value of color<br>
&lt;alisonmaher> q+<br>
&lt;iank_> I'm getting very warbled audio - is this is the for others?<br>
&lt;fremy> fantasai: (if you are not inheriting from outside, then we don't reset the color)<br>
&lt;fantasai> alisonmaher: I agree with the proposal<br>
&lt;astearns> ack alisonmaher<br>
&lt;fantasai> alisonmaher: only problem I wanted to ask about was whether we can do at computed value time<br>
&lt;fantasai> alisonmaher: if we take the used value of the color, might expose the color where otherwise wouldn't<br>
&lt;fantasai> TabAtkins: :visited won't be exposed that way<br>
&lt;fantasai> TabAtkins: that's done by selector-hacking<br>
&lt;fantasai> TabAtkins: and the rest of colors are already automatically exposed via getComputedStyle<br>
&lt;fantasai> TabAtkins: because gCS returns used value of color<br>
&lt;Rossen_> q<br>
&lt;fantasai> TabAtkins: so not sure there's info leakage problem<br>
&lt;fantasai> Rossen_: While we're on the topic, wrt TAG review<br>
&lt;fantasai> Rossen_: We convinced ourselves that having a grouping of color values that we essentially return just defaults for, and lie about the computed or used values<br>
&lt;fantasai> Rossen_: colors used for fingerprinting<br>
&lt;fantasai> Rossen_: could be a good path forward<br>
&lt;fantasai> Rossen_: These are magic values, you won't get the actual values though gCS<br>
&lt;fantasai> Rossen_: benefit of user for privacy<br>
&lt;astearns> ack fantasai<br>
&lt;fremy> fantasai: this is a different issue though<br>
&lt;fantasai> fantasai: That's a separate issue, here https://github.com/w3c/csswg-drafts/issues/5710<br>
&lt;fremy> fantasai: in that issue there are further comments there that says why it's probably not possible<br>
&lt;fremy> fantasai: but this is not linked to our current issue here<br>
&lt;fantasai> astearns: If we end up doing anything special for particular sources of colors<br>
&lt;fantasai> astearns: if we add this new mechanism, we'd have to do whatever magic here, too<br>
&lt;fantasai> fantasai: You'd also have to taint Canvas, and a lot of other things, yeah.<br>
&lt;fantasai> astearns: alisonmaher is it enough to note that, whatever protections would end up happening here also?<br>
&lt;fantasai> alisonmaher: We're storing [?] in chrome, so would be possible to do at used-value time<br>
&lt;fremy> fantasai: the issue is that would have to track this down the tree<br>
&lt;fremy> fantasai: and this type of tracking is usually done via inheritance<br>
&lt;fremy> fantasai: I don't think implementations have a special inherit for colors<br>
&lt;fantasai> alisonmaher: We inherit that info separately in Chromium<br>
&lt;fantasai> astearns: So what do we resolve to deal with this<br>
&lt;fremy> fantasai: we need to add a new value<br>
&lt;fantasai> fantasai: We need to a new value to forced-color-adjust<br>
&lt;fantasai> fantasai: as described in https://github.com/w3c/csswg-drafts/issues/6310#issuecomment-858112357<br>
&lt;fantasai> fantasai: We can call it something else, but need something that behaves like that<br>
&lt;fantasai> astearns: New value, not something to add to default?<br>
&lt;fantasai> TabAtkins: Yes, absolutely<br>
&lt;fantasai> TabAtkins: and needs to be set in default UA stylesheet for SVG root element<br>
&lt;fantasai> astearns: exposed to author styles?<br>
&lt;fantasai> TabAtkins: yes; don't want it to be special unspecifiable magic<br>
&lt;fantasai> astearns: So proposed resolution is to add this keyword<br>
&lt;fantasai> astearns: and to add that to the defautl UA stylesheet<br>
&lt;fantasai> RESOLVED: Add new keyword to forced-color-adjust as described above, apply it in UA default stylesheet for SVG root element<br>
&lt;fremy> fantasai: other than this issue<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/labels/css-color-adjust-1<br>
&lt;fremy> fantasai: we have no other remaining issue for the spec<br>
&lt;fremy> fantasai: so our plan is to make the edit<br>
&lt;fremy> fantasai: publish a new draft<br>
&lt;fremy> fantasai: and ask for last comments before trying to propose to make a recommendation<br>
&lt;fremy> fantasai: so, heads up<br>
&lt;fremy> astearns: and get wide review?<br>
&lt;fremy> fantasai: we already have sent an email (... missed)<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/issues/5768<br>
&lt;fantasai> in December<br>
&lt;fremy> astearns: sounds like a good plan<br>
</details>


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


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

Received on Wednesday, 16 June 2021 16:18:24 UTC