[csswg-drafts] [css-values] <percentage> shouldn't be able to resolve to <number> in calc()

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

== [css-values] <percentage> shouldn't be able to resolve to <number> in calc() ==
In #1462, I talk about the problems inherent in letting "number"-typed expressions in calc() ever resolve as equivalent to "length"/"angle"/etc expressions.  This was already disallowed in Level 3 calc(), so it was okay.

However, I just realized that Level 3 calc() *does* allow `<number>` and `<percentage>` to be equivalent, which brings up the exact same issues.

Now, *in plain CSS*, the difference doesn't really matter - because `<number>`s can multiple with each other endlessly, it's okay to have an expression like `calc(1% * 1%)` for 'opacity' (as it resolves to "number"), but the exact same calc() would fail immediately in 'width' (as its type would be length²).  Similarly, it would mean that `calc(1 + 1%)` is valid in 'opacity' but invalid in 'line-height'.  This all complicates the rules quite a bit in Level 4 calc(), or Typed OM.

I propose that we amend calc() to prevent `<percentage>` from resolving against `<number>`.  This has no practical effect on devs - since `<number>` and `<percentage>` are just rescaled "units" in 'opacity', there's never a *need* to add them together in calc, or multiply two or more percentages (you can just convert them to numbers by shifting the decimal point, *then* add/multiply them).  However, it *drastically* simplifies the necessary type-tracking spec text I'm writing for Typed OM (which Level 4 calc() will reuse).

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

Received on Thursday, 25 May 2017 09:13:24 UTC