- From: Sam Weinig via GitHub <noreply@w3.org>
- Date: Sat, 25 Apr 2026 18:50:39 +0000
- To: public-css-archive@w3.org
weinig has just created a new issue for https://github.com/w3c/csswg-drafts:
== [css-values] Clarifications on how should calc-mix() simplification should work ==
I starting to try and implement [calc-mix()](https://drafts.csswg.org/css-values-5/#calc-mix) and I am not sure when its ok to simplify the function.
Let's use an example to make things explicit:
```html
<!DOCTYPE html>
<html>
<body>
<pre id="output"></pre>
<div style="width: 200px">
<div id="test" style="text-indent: calc-mix(10px 50%, 20px)"></div>
</div>
<script>
const test = document.getElementById('test');
const output = document.getElementById('output');
output.textContent += `#test: specified = ${test.style["text-indent"]}\n`;
output.textContent += `#test: computed = ${getComputedStyle(test)["text-indent"]}\n`;
</script>
</body>
</html>
```
This could print out something like:
```
#test: specified = calc-mix(10px 50%, 20px 50%)
#test: computed = 15px
```
(The 15px comes from evaluating the calc-mix like this: (10px * 0.5) + (20px * 0.5) = (5px + 10px) = 15px. Is this right? No where is the algorithm for evaluating calc-mix defined, it just states "The [used value](https://drafts.csswg.org/css-cascade-5/#used-value) of a valid [mix notation](https://drafts.csswg.org/css-values-5/#mix-notations) is the weighted average of its arguments" but doesn't define what it means by "weighted average").
Question 1: Should the specified value serialization include the normalized percentages (e.g. filled in the second 50%)?
Question 2: Should the specified value serialization be simplified down to just `calc(15px)` instead?
Making the example a bit more complicated, let's change the calc-mix to `calc-mix(10em 50%, 20px)`. Now, we can't simplify at specified value time, since we can't resolve the `em` values.
Is the correct output now?
```
#test: specified = calc-mix(10em 50%, 20px 50%)
#test: computed = 90px
```
Question 3: Should the specified value serialization have been simplified down to products and sums (e.g. `#test: specified = calc((10em * 0.5) + (20px * 0.5))`)?
Going one step further, let's change the calc-mix to `calc-mix(25% 50%, 20px)`. Now we can't simplify even at computed value time, since we can't resolve the percentage value.
Is the correct output now?
```
#test: specified = calc-mix(25% 50%, 20px 50%)
#test: computed = calc-mix(25% 50%, 20px 50%)
```
Finally, what about 0% items. Let's change the calc-mix to `calc-mix(25% 50%, 20px, 300px 0%)`.
Is the correct output still?
```
#test: specified = calc-mix(25% 50%, 20px 50%)
#test: computed = calc-mix(25% 50%, 20px 50%)
```
Question 4: Should 0% terms be dropped from the specified and/or computed value serializations?
--
I think one thing that would make this (and future functions added to calc()'s repertoire) easier from an implementors standpoint is if there were a clearer way for functions to be defined. Ideally something like CSS Values 4 (the base calc() spec work) would define what a function needed to work in calc() via a set of named conformance hooks, and each new function would declare how it should behave when those hooks are invoked. Some of this happens already via declaring how the arguments affect type checking with "[consistent type](https://drafts.csswg.org/css-values-4/#css-consistent-type)" concept, but its a bit adhoc.
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13839 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 25 April 2026 18:50:40 UTC