Re: [csswg-drafts] [css-properties-values-api] `light-dark()` and system colors in initial values (#12735)

The CSS Working Group just discussed ``[css-properties-values-api] `light-dark()` and system colors in initial values``, and agreed to the following:

* `RESOLVED: Add an example as to why this case is computationally independent`

<details><summary>The full IRC log of that discussion</summary>
&lt;ydaniv> TabAtkins: props and values API says initial values have to be computationally independent<br>
&lt;ydaniv> ... question is does this mean that stuff like color scheme are not computationally independent?<br>
&lt;ydaniv> ... answer is yes, I don't think we need to add anything, it follows the definition<br>
&lt;miriam> q+<br>
&lt;ydaniv> ... since someone thought this is unclear, we could add a note<br>
&lt;weinig> q+<br>
&lt;ydaniv> ... I think we can resolve close no change<br>
&lt;ydaniv> dbaron: what's the current state of computed scheme colors?<br>
&lt;weinig> q-<br>
&lt;ydaniv> emilio: I think we ended up computes to color<br>
&lt;kbabbitt> system colors compute to color values<br>
&lt;dbaron> s/computed scheme/the computed value of system colors.  Does it compute to keywords or to/<br>
&lt;astearns> ack miriam<br>
&lt;ydaniv> miriam: I think that's right in existing spec, my question is do we need to keep this restriction?<br>
&lt;ydaniv> ... it's not the way authors think about custom properties<br>
&lt;emilio> q+<br>
&lt;ydaniv> ... if we don't need it we should not have it<br>
&lt;astearns> ack emilio<br>
&lt;ydaniv> emilio: it would be quite weird<br>
&lt;ydaniv> ... it's a restriction custom properties is known to have, I'd have to think how easy it is to remove this restriction<br>
&lt;ydaniv> TabAtkins: we have some color stuff here that is used as initial values in custom properties, but between the color property itself and several other properties which depend on other properties, it's a funky case<br>
&lt;emilio> color is also not quite that, because currentcolor computes to itself<br>
&lt;ydaniv> ... however, outside of color where we do use initial value like em it's calculated like initial em<br>
&lt;emilio> q+<br>
&lt;ydaniv> ... it seems weird to authors it's not resolving the same as set on the element they set it on<br>
&lt;ydaniv> miriam: I get the complexity, but authors don't have a good way to set a global initial defaults<br>
&lt;ydaniv> ... it needs a lot more teaching, or some better way to help authors set both, global defaults that can be relative, and initial value<br>
&lt;ydaniv> TabAtkins: would love to chat more on the use-cases, and see what are your expectations<br>
&lt;astearns> ack dbaron<br>
&lt;ydaniv> dbaron: one thought is what an initial value means is different between inherited and non-inherited<br>
&lt;ydaniv> ... on inherited it's used only on the root, as opposed to non-inherited<br>
&lt;ydaniv> ... if you wanted this it would be harder to work around the non-inherited ones<br>
&lt;astearns> ack fantasai<br>
&lt;astearns> ack emilio<br>
&lt;ydaniv> astearns: miriam would want to discuss the general authoring problems here?<br>
&lt;ydaniv> miriam: will open a new one<br>
&lt;ydaniv> astearns: so for this resolution we decide to add an example?<br>
&lt;ydaniv> TabAtkins: yeah<br>
&lt;ydaniv> PROPOSED RESOLUTION: Add an example as to why this case is computationally independent<br>
&lt;ydaniv> astearns: objections?<br>
&lt;ydaniv> RESOLVED: Add an example as to why this case is computationally independent<br>
</details>


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


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

Received on Wednesday, 11 March 2026 15:50:18 UTC