Re: [csswg-drafts] [css-values-5] Computed (vs used) value of mix() functions (#12290)

The CSS Working Group just discussed `[css-values-5] Computed (vs used) value of mix() functions`, and agreed to the following:

* `RESOLVED: simplify as much as possible (combining items when it can) for computed value`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> fantasai: we have mix() that compute a weighted average from a list of items and %s<br>
&lt;TabAtkins> fantasai: sometimes you can compute it to a final value, others you need to keep values distinct until used value time<br>
&lt;TabAtkins> fantasai: we have two ways of simplifying we could take<br>
&lt;TabAtkins> fantasai: one is to simplify as much as possible, including collapsing some items in the list<br>
&lt;TabAtkins> fantasai: or we can just simplify each argument, preserving the number of items<br>
&lt;TabAtkins> fantasai: so your computed value serialization would be either a single value, or a list with same number of items as previous. no halfway point like in the first option<br>
&lt;emilio> I think whatever calc() does?<br>
&lt;TabAtkins> fantasai: currently we've specced the second option since it seems simpler, wanted opinions<br>
&lt;TabAtkins> calc() does first options<br>
&lt;TabAtkins> astearns: doesn't first option lose info?<br>
&lt;TabAtkins> astearns: how would I be able to look at list of values and get an average if I didn't know how many itmes where there?<br>
&lt;TabAtkins> fantasai: each item has a weight, so your combined item has the combined weight<br>
&lt;TabAtkins> fantasai: [gives example]<br>
&lt;TabAtkins> astearns: ah, makes sense<br>
&lt;lea> no opinion either<br>
&lt;TabAtkins> astearns: slight preference for second, it preserves more of author intent<br>
&lt;TabAtkins> astearns: and this is hopefully an edge case<br>
&lt;lea> +1<br>
&lt;kbabbitt> also lean slightly toward option 2<br>
&lt;emilio> q+<br>
&lt;TabAtkins> TabAtkins: Emilio commented in chat, seemed to lean option 1<br>
&lt;astearns> ack emilio<br>
&lt;TabAtkins> emilio: is there a reason to not be consistent with calc? max simplification?<br>
&lt;lea> What does min()/max() do? That might be a better precedent than calc() as it has multiple arguments too<br>
&lt;TabAtkins> fantasai: calc() is hierarchical, you kinda combine things that are adjacent until they can't be combined any more<br>
&lt;TabAtkins> fantasai: in mix(), if first and last can be combined, middle can't, you'll get a combined item that has to go first or last...<br>
&lt;TabAtkins> emilio: I think we should simplify nested mix() if possible, and that bubbles<br>
&lt;TabAtkins> fantasai: yes, if you can collapse a mix() into one value, you do that. this is if at least one item can't be combined<br>
&lt;TabAtkins> emilio: ah kk, thought you were never simplifying<br>
&lt;TabAtkins> fantasai: nah, just if one item can't be simplified<br>
&lt;fantasai> TabAtkins: min()/max() simplify by combining items, so that's a precedent<br>
&lt;fantasai> TabAtkins: from some feedback from smfr back in the day<br>
&lt;TabAtkins> astearns: should we go with option 1 then, for precedent?<br>
&lt;TabAtkins> fantasai: it's a little easier for min/max since you just drop some, while here you have to change values, but it's certainly doable<br>
&lt;TabAtkins> astearns: so proposed is to simplify as much as possible (combining items when it can) for computed value<br>
&lt;TabAtkins> fantasai: I feel like manipulating the result will be odd, but...<br>
&lt;TabAtkins> RESOLVED: simplify as much as possible (combining items when it can) for computed value<br>
</details>


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


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

Received on Wednesday, 24 September 2025 15:26:45 UTC