- From: Sam Weinig via GitHub <noreply@w3.org>
- Date: Tue, 28 Apr 2026 16:24:52 +0000
- To: public-css-archive@w3.org
cc @tabatkins, @fantasai I also put up a PR in the WPT repo with some tentative tests for `calc-mix()`, https://github.com/web-platform-tests/wpt/pull/59515. I picked the following answers for the questions above: > Question 1: Should the specified value serialization include the normalized percentages (e.g. filled in the second 50%)? - Yes, if the normalization can be completed. In cases where it can't, like `calc-mix(1 calc(10% * sibling-index(), 2)` (here, because `sibling-index()` isn't resolvable at specified value time), it is left un-normalized. > Question 2: Should the specified value serialization be simplified down to just `calc(15px)` instead? - Yes, if it can be fully simplified it should be. > 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)))? - No. `calc-mix()` should not be converted to its products and sums form. > Question 4: Should 0% terms be dropped from the specified and/or computed value serializations? - Yes, 0% terms should be dropped as aggressively as possible, including cases where other normalization is not possible. The thorny question remains of what to do in `<length-percentage>` when all the terms have 0% weights, and the values are a mix of `<length>` and `<percentage>`. For example `calc-mix(10% 0%, 10px 0%)`. In the tentative WPT tests, and the WebKit implementation, I have chosen to resolve that to match the type of the first term, so in this case it would be `calc(0%)`. Had the terms been switched, `calc-mix(10px 0%, 10% 0%)`, it would be `calc(0px)`. I am not super satisfied with that decision, but I figured having something was a good starting point for discussion. -- GitHub Notification of comment by weinig Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13839#issuecomment-4337164840 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 28 April 2026 16:24:53 UTC