[csswg-drafts] [css-values] specification for calc() should be clearer about when the result has a percentage (#10017)

dbaron has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-values] specification for calc() should be clearer about when the result has a percentage ==
There are a number of cases where layout algorithms in CSS (and perhaps other things) care about whether a value has a percentage.  In particular, values that have a percentage are treated differently when there's nothing for the percentage to resolve against:  inside of something with `auto` height a `height: calc(30px)` is a fixed value but a `height: calc(30px + 0%)` is treated as `height: auto`.

With `calc()` as it was specified in css-values-3, this could essentially be implemented as part of the type computation; a `calc()` expression could effectively be either a `<length>` or a `<length-percentage>` as its toplevel type, and those that were `<length-percentage>` act as though they have a percent.

Newer levels of the specification introduce features that make this approach insufficient:
* division by values with units
* [`sign()`](https://drafts.csswg.org/css-values-4/#calc-type-checking)
* [`progress()` and related functions](https://drafts.csswg.org/css-values-5/#progress)
* [`calc-size()`](https://drafts.csswg.org/css-values-5/#calc-size)

(I think this is clearly defined for `calc-size()` because it's very important there, but I don't think it's clearly defined for the other cases.)

It should be clearer whether these other things "erase" the percentage-ness of their arguments when they erase the types of those arguments, or whether they still produce toplevel values that are treated as having a percentage.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10017 using your GitHub account


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

Received on Thursday, 29 February 2024 20:26:07 UTC