- From: Tab Atkins Jr. via GitHub <noreply@w3.org>
- Date: Fri, 27 Mar 2026 20:41:18 +0000
- To: public-css-archive@w3.org
The current spec avoids these sorts of functions on purpose, precisely for the reasons given by @Loirooriol - it means we must resolve the value at parse-time, essentially, and if a value has already been resolved and canonicalized (for example, a `2em` value set on a `<length>`-syntax custom property, then substituted with `var()`), you get confusing, unexpected results (or we're required to associate the original source string with the value and carry that thru the system, just in case someone asks for the original value). Similarly, existing functions that *would* have the same issue (`pow()`) take pains to avoid that (by requiring their arguments to be numbers). Being able to extract the numeric value or swap the unit *does* make sense, but the way you do it is with unit division, which makes it clear what unit you expect the value to be interpreted in. `calc(5px / 1px)` yields 5, `calc(1in / 1px)` yields 96, etc. And to convert the value to another unit, you just follow it with a multiplication: `calc(5px / 1px * 1em)`. This works for *all* numeric values (not just explicitly specified ones) and is robust against canonicalization or conversion. If you wrote a value originally in `em`s, then when you divide it by `1em` you'll get the number of `em`s even if it's been converted to `px` in the interim. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13550#issuecomment-4145131675 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 27 March 2026 20:41:18 UTC