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 multiply 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).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3