- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 13 May 2026 16:52:21 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-color-5] `light-dark()` should resolve at used value time, not computed value time``. <details><summary>The full IRC log of that discussion</summary> <astearns> zakim, open queue<br> <Zakim> ok, astearns, the speaker queue is open<br> <TabAtkins> lea: we ahve a resolution that system colors compute to their actual value, not themselves<br> <TabAtkins> lea: motivated by an emilio example about authors using system colors and them inheriting into descendants<br> <TabAtkins> lea: but, people define colors in css varaibles today<br> <TabAtkins> lea: the mental model people mostly have is that light-dark() is dynamic and adapts to the color scheme used<br> <TabAtkins> lea: instead what we do, because light-dark() computes to one of its arguments based on the element it's used on<br> <TabAtkins> lea: so if you define colors on root, it'll base on the root element's scheme<br> <TabAtkins> lea: you could say, don't register the property as a <color>, but there's good reason to do so<br> <TabAtkins> lea: there's also othe rproperties, color and accent-color<br> <TabAtkins> lea: common to set that on an ancestor and just let it filter thru<br> <TabAtkins> lea: but if you set accent-color on a parent then change color-scheme on a descendant, those dont' change<br> <TabAtkins> q+<br> <astearns> ack futhark<br> <TabAtkins> lea: that seems to be a bigger footgun than what motivated the resolution<br> <TabAtkins> lea: authors do not frequently change background along with color-scheme, that was the worry<br> <TabAtkins> lea: but having colors resolve at the point it's used seems like saying a semi-transparent color shoudl composite where it's used<br> <TabAtkins> lea: so, is the original resolution a desirable change? best for authors? and what's the impl complexities about making them resolve at used time? is it web compatible?<br> <TabAtkins> lea: right now it looks like it *might* be possible, but is tricky<br> <kbabbitt> q+<br> <TabAtkins> lea: currently used on (missed) % of pages<br> <TabAtkins> lea: so there are footguns. but i think current bheavior's footguns are easier to run into<br> <kizu> q+<br> <JoshT> s/(missed)/1.23%/<br> <TabAtkins> lea: oh, and authors have the messaging right now that registering your property type makes it animatable/etc which is good.<br> <fantasai> +1 to lea's concerns<br> <astearns> ack TabAtkins<br> <lea> TabAtkins: debated this but I think we resolved correctly<br> <lea> q+<br> <lea> TabAtkins: if we allow system colors to change as they inherit based on the current color scheme, non inherited colors will not change with it. If you correctly set a color pair and one of them is a system color, one of them will change on a descendant, the other one will not<br> <lea> TabAtkins: that is a very easy way to make your text unreadable<br> <lea> TabAtkins: suddenly become unreadable even though you didn't change any of them, you changed a third property<br> <emilio> +1<br> <lea> TabAtkins: with the current behavior even though your colors don't match the current color scheme, at least they will both be readable<br> <emilio> q+ to say that I don't understand why this is different from any other computed value change like em -> px, I think the current behavior seems reasonable<br> <lea> TabAtkins: always some possibility of confusion here but the big problem, the very easy to hit problem wasn't the text color changing but the background color not changing and that happening automatically<br> <lea> TabAtkins: and light-dark() needs to be the same because [missed]<br> <lea> TabAtkins: not a big problem because changing color-scheme is rarely done on individual elements<br> <lea> TabAtkins: aside from examples e.g. design system documentation<br> <miriam> q+<br> <astearns> s/same because [missed]/same as system color because they are connected/<br> <lea> TabAtkins: I don't see a reason to ever change the color scheme of individual elements, so I don't think this is something people will actually run into<br> <lea> TabAtkins: and that will be immediately visible, you'll spot it<br> <JoshT> At the BBC, we have use cases for changing the colour scheme on an individual element<br> <lea> TabAtkins: so I think we should stick to the current resolution<br> <astearns> ack kbabbitt<br> <TabAtkins> kbabbitt: another thing is that light-dark() can be composed with color-mix()/etc<br> <TabAtkins> kbabbitt: currentcolor usage requires maintaining a tree of unresolved colors<br> <TabAtkins> kbabbitt: concerned it's annoying/confused to have that happen more often<br> <TabAtkins> kbabbitt: i want to keep them all consistent if possible<br> <astearns> ack kizu<br> <TabAtkins> kizu: i commented today - i think i agree the current behavior is more accepted, at least for me<br> <TabAtkins> kizu: i'm quite afraid of global regressiosn if we do change it<br> <TabAtkins> kizu: another possible break if we flip it is that container-style queries that check the value of a system color will break if we change it<br> <JoshT> q+<br> <kbabbitt> to clarify, my point was about timing of resolution - I'd want to keep light-dark, color-mix, rcs all consistent about the time they resolve<br> <emilio> Yeah, to add to what kbabbitt said, all colors generally resolve to "currentColor or an absolute color" at computed value time, and `getComputedStyle` resolves `currentColor` on top... Would `getComputedStyle` start returning `light-dark()` or...<br> <TabAtkins> kizu: i also wonder if it makes sense to have an option for this<br> <emilio> +1 kbabbitt<br> <astearns> ack lea<br> <TabAtkins> kizu: so your custom property doesn't evaluate, it just checks its syntax but otherwise stays unresolved until usage, like an unregisterd dproperty<br> <fantasai> emilio, no it would continue to return the resolved color<br> <TabAtkins> lea: would push back on TAb's claim where it can't result in unreadable, i posted some examples of that.<br> <JoshT> +1<br> <emilio> But `computedStyleMap` would start returning the `light-dark(..)` tree<br> <TabAtkins> lea: that was my concern, it seemed the problem was theoretical<br> <emilio> fantasai: ^ (sorry, irc-only today)<br> <TabAtkins> lea: in practice when they set color-scheme, they don't set it on a transparent bg element, they set it on a "panel" with a bg color<br> <TabAtkins> lea: [missed an example about an element that's alway sthe opposite of the page scheme]<br> <TabAtkins> lea: we don't need to change the system color resolution, they're defined in light-dark() so they'll change to match<br> <TabAtkins> lea: but accent-color...<br> <TabAtkins> lea: system colors are basically the built-in design tokens<br> <emilio> lea, but system colors behave like light-dark() right?<br> <TabAtkins> lea: also if color-scheme shouldn't be use don elements, we maybe shouldn't have the property, weird to have it a sosmething people shouldn't use<br> <TabAtkins> lea: but there are also valid use-cases where we want it be on individual elements<br> <fantasai> emilio, yes, ideally the system colors are defined in terms of light-dark() ...<br> <TabAtkins> lea: to kevin, we alreayd have this inconsistency with currentcolor<br> <emilio> forcing a popup / etc to use `color-scheme: <something different>` seems pretty reasonable<br> <lea> qq+<br> <TabAtkins> TabAtkins: Note: we have color-scheme property because we invented it first; if time machine we'd have done the html meta first<br> <astearns> ack lea<br> <Zakim> lea, you wanted to react to lea<br> <astearns> ack emilio<br> <Zakim> emilio, you wanted to say that I don't understand why this is different from any other computed value change like em -> px, I think the current behavior seems reasonable<br> <TabAtkins> TabAtkins: and then the primary case would be whole page consistent<br> <emilio> If you have length design tokens you can't type them if you want to react to children font size changes. I get the confusion but I think the current behavior seems pretty reasonable and consistent with that.<br> <lea> TabAtkins: color-scheme affects UA-generated UI, so it's incredibly useful when you have overall dark elements<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to ask why someone would set color-scheme without also setting a color scheme with color and background color<br> <TabAtkins> emilio: [comment is read out]<br> <TabAtkins> fantasai: Tab is asserting the problem is you'd have a problem if you change color-scheme without setting background<br> <lea> +1 fantasai, I made that point too. Literally all use cases of element-specific `color-scheme` I have seen are surfaces and they have their own background<br> <TabAtkins> fantasai: don't understand why you'd do that anyway; color-scheme should always be set along with background<br> <TabAtkins> fantasai: we could be more explicit about that in the spec<br> <emilio> lea, fantasai, a non-theoretical use case is `forced-color-adjust: none`<br> <astearns> ack miriam<br> <emilio> This is what prompted the system color issue<br> <TabAtkins> emilio: so the idea that an author woudl flip the color scheme without changing the background seems odd. but flipping both seems liek a reasonable thing to do<br> <TabAtkins> miriam: i got on to say there are a lot of reasons to do this on a per-element basis<br> <fantasai> s/emilio/fantasai<br> <emilio> E.g., you have a subtree where you set `forced-color-adjust: none` and forget to set foreground / background and now stuff looks terrible<br> <fantasai> s/flipping both/flipping both on a subtree/<br> <TabAtkins> miriam: but i don't have much opinion on changing this for the specific issue. but i think we need a general solution for "i need a variable to hold something without resolving it"<br> <TabAtkins> miriam: more clear than registering vs not registering<br> <TabAtkins> q+<br> <TabAtkins> miriam: not clear to authors that holding it as a string requires unregistering; getting animations makes it break...<br> <TabAtkins> miriam: i think it's nice that setting color-scheme on the root changes the background anyway. so i agree with fantasai about that<br> <astearns> ack JoshT<br> <TabAtkins> miriam: i often want all the associated colros from a color scheme<br> <fantasai> +1 to miriam<br> <TabAtkins> JoshT: +1 to what miriam just said.<br> <lea> q+<br> <TabAtkins> JoshT: find it bizarre that color-scheme property is explained in the spec as choosing based on the element color scheme, but now light-dark() is using the page color scheme<br> <TabAtkins> (that's not correct)<br> <TabAtkins> JoshT: that's really confusing to me as an author<br> <astearns> ack TabAtkins<br> <lea> TabAtkins: light-dark() doesn't use the page color scheme, it uses the color-scheme of the element it's used on, the use case here is variables defined on the root, so they use the page theme<br> <lea> TabAtkins: to what lea and miriam were saying, i agree lazy resolve is a valuable capability<br> <lea> TabAtkins: that is in fact how the system colors work, canvastext resolves on that element at computed value time<br> <lea> TabAtkins: that's different than what we get with these design tokens<br> <miriam> +1, it's a general issue<br> <lea> TabAtkins: same underlying mechanism, additional mechanism about where and when they resolve<br> <lea> TabAtkins: having a switch that says "don't resolve this yet" would be good<br> <JoshT> +1<br> <lea> TabAtkins: e.g. a variable that can stay unresolved until explicitly resolved via some mechanism e.g. when used into a non-custom property<br> <lea> TabAtkins: this would give us this functionality, define your design tokens in the root, resolve at usage point<br> <lea> TabAtkins: that is also something we should be pursuing<br> <lea> TabAtkins: and that's the way to pursue it<br> <emilio> Agree, though it'd probably break animation, or we'd need to define animations between specified values<br> <astearns> ack lea<br> <bramus> +1 to Tab<br> <TabAtkins> lea: i agree ath if you set color-scheme you're generally setting background as well<br> <TabAtkins> lea: while to work aroudn *this* case you have to set declarations in a way that doesn't reflect your intent<br> <TabAtkins> lea: you have to *not* register your --accent-color property<br> <TabAtkins> lea: if you *do* register it, you have to redefine it at the elements that change color-scheme<br> <TabAtkins> lea: i think Tab's suggestion is great to do, but it doesn't fix the footguns<br> <TabAtkins> lea: it's great if there are workarounds to reach for, but there are alreayd workarounds<br> <TabAtkins> lea: problem is that colors just aren't working as authors are expecting<br> <TabAtkins> lea: all inherited color proeprties need to be redefined<br> <TabAtkins> lea: so it's not just about design tokens<br> <TabAtkins> lea: for system colors, on webkit they're defined as using light-dark()<br> <TabAtkins> lea: and Tab mentioned, not changing color-scheme on individual elements<br> <TabAtkins> lea: but since it affects UI like scrollbars, you can change all of them as well to match an otherwise dark element, like a code editor (often dark even if the overall UI is light)<br> <TabAtkins> lea: spelling underlines, etc<br> <TabAtkins> (i'm still with Emilio, the exact same concern occurs for all length properties that use ems)<br> <TabAtkins> astearns: sounds like we don't hav econsensus, but q is empty, let's take it back to the 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/13836#issuecomment-4443352102 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 13 May 2026 16:52:23 UTC