Re: [csswg-drafts] [css-color-adjust] Used color-scheme should affect the root element color, not initial color (#4608)

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

* `RESOLVED: use "canvastext" as the initial value of color`

<details><summary>The full IRC log of that discussion</summary>
&lt;fremy> Topic: Color-Adjust<br>
&lt;astearns> github: https://github.com/w3c/csswg-drafts/issues/4608<br>
&lt;tantek> fantasai, my use-case is one I tried to make work but couldn't. I was trying to make the initial letters in a blog post of A-Z that resembled classic wooden building blocks and couldn't :(<br>
&lt;fremy> TabAtkins: the spec says that color-scheme on the root element affects the initial value of the color property<br>
&lt;fremy> TabAtkins: in addition to a couple of other things<br>
&lt;fremy> TabAtkins: the argument is that we should instead change the color of the root in the UA, but not the initial color value<br>
&lt;fremy> TabAtkins: I am not sure why this was proposed, but I see more value in our current spec<br>
&lt;fremy> TabAtkins: because I don't see a value to get black as color when you're in the dark theme<br>
&lt;fremy> TabAtkins: if we changed the initial value, a weird thing I do currently in Bikeshed would work better though<br>
&lt;astearns> ack jfkthame<br>
&lt;fremy> TabAtkins: a detail of this, is that the actual used color in chrome and safari is that it's actually a color that switches its value at computed value time<br>
&lt;fremy> TabAtkins: in safari it's system-color and in blink a custom ua value<br>
&lt;fremy> TabAtkins: and I think that this is a useful behavior<br>
&lt;fremy> TabAtkins: so I tried to find an alternative behavior<br>
&lt;heycam> q+<br>
&lt;fremy> TabAtkins: we say the initial value of color is "text", and "initial" would work as usual<br>
&lt;hober> q?<br>
&lt;fremy> TabAtkins: I think it's ok because all uses of "color" is in property that require to return the used value at getComputedStyle so I'm unsure this would be observable<br>
&lt;tantek> except for scrollbar-color, which has keywords that are returned<br>
&lt;fremy> TabAtkins: but it would be visible in TypedOM<br>
&lt;fremy> TabAtkins: can we get an agreement to match what Safari does in this case?<br>
&lt;astearns> ack fantasai<br>
&lt;Zakim> fantasai, you wanted to ask about SVG<br>
&lt;fremy> fantasai: A question I have is that this could cause issues in SVG, right?<br>
&lt;fremy> TabAtkins: by default, it is, yeah<br>
&lt;fremy> TabAtkins: but I'm not sure what the expectation what would be<br>
&lt;fremy> heycam: it's more common to use black as the default value<br>
&lt;fremy> TabAtkins: and it's mostly relevant for text, for which you usually you would want to switch<br>
&lt;hober> q+<br>
&lt;fremy> emilio: you use currentColor in SVG to get that effect<br>
&lt;fremy> emilio: not the default<br>
&lt;fremy> TabAtkins: the initial value is black, and also fill is black<br>
&lt;fremy> TabAtkins: so that change wouldn't affect anything by default in SVG<br>
&lt;astearns> ack heycam<br>
&lt;fremy> Rossen: if it did break SVG, we would notice and backtrack<br>
&lt;fremy> heycam: if you don't reset the property value, and inherit<br>
&lt;fremy> heycam: does the value switch for the children that inherited that complex value?<br>
&lt;fremy> fantasai: keywords inherit as a keyword, it's gonna be ok<br>
&lt;fremy> heycam: really?<br>
&lt;fremy> fantasai: yes, the keyword is inherited and behave per the element<br>
&lt;astearns> ack hober<br>
&lt;fremy> fantasai: but getComputedStyle returns a resolved value which is a color<br>
&lt;fremy> hober: if the change is compatible with what we already do, and we allow the ua stylesheet to use that paradigm for the color<br>
&lt;emilio> Rossen: so if you animate between `CanvasText` and `Canvas`, for example... How is that supposed to work? Does it become a discrete animation?<br>
&lt;fremy> TabAtkins: I haven't verified that myself<br>
&lt;heycam> q+<br>
&lt;fantasai> s/Rossen:/Rossen,<br>
&lt;fremy> (safari team is checking)<br>
&lt;fremy> emilio: I would like to question the interpolation between keyword values<br>
&lt;fremy> Rossen: you interpolate between the values<br>
&lt;fremy> emilio: but we can't write that value anywhere<br>
&lt;fremy> TabAtkins: I guess right now we cheat<br>
&lt;fremy> TabAtkins: we resolve the keyword, then interpolate, even though we inherit the keyword<br>
&lt;fremy> TabAtkins: just like currentColor since we switched the value<br>
&lt;fremy> emilio: we use some hack to make it work<br>
&lt;fremy> emilio: which relies on a bit to know how to do that<br>
&lt;fremy> emilio: but we don't want to add a bit for each system color<br>
&lt;fremy> TabAtkins: we are going to add interpolate() eventually to fix this<br>
&lt;chris> s/a bit/a hack/<br>
&lt;chris> s/a bit/a hack/<br>
&lt;fremy> hober: the UA stylesheet when the color scheme is built-in sets the color property to the value Text on the root element<br>
&lt;astearns> ack heycam<br>
&lt;fremy> TabAtkins: so what I am proposing is virtually the same as what I am proposing<br>
&lt;fremy> hober: right<br>
&lt;TabAtkins> from hober: WebKit's UA stylesheet sets html { color: text; } if the color scheme feature flag is on<br>
&lt;fantasai> https://www.w3.org/TR/css-color-4/#css-system-colors<br>
&lt;fantasai> System colors that are not deprecated ^<br>
&lt;fremy> heycam: in color-4 we say what to do with the undeprecated values<br>
&lt;TabAtkins> s/as what I am proposing/as what you're currently doing/<br>
&lt;fremy> Rossen: before I formally say yes, let me check<br>
&lt;fremy> fantasai: it's definitely there<br>
&lt;fremy> Rossen: ok then<br>
&lt;fremy> heycam: also for background colors?<br>
&lt;fremy> fantasai: yes<br>
&lt;fremy> Rossen: so we want to resolve on this proposal?<br>
&lt;fremy> astearns: no objection?<br>
&lt;fremy> RESOLVED: use "canvastext" as the initial value of color<br>
</details>


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

Received on Friday, 24 January 2020 14:25:57 UTC