-
Notifications
You must be signed in to change notification settings - Fork 733
Description
In many properties, %s are resolved against some other type, and are thus treated like that type in calc(); you can do calc(1% + 1px)
, for example. There are a small number of properties that do the same thing for numbers; I believe so far it's just 'line-height' and 'tab-size'. Theoretically, we should be able to add these, too - there's nothing theoretically wrong with line-height: calc(1 + 2px);
.
In practice, there are some problems. In level 3 calc(), if we allowed it, we'd have to treat "number + length" differently than "number * length" - it's a length-like in the first case, but just a raw number in the second case. In level 4 calc() we'd have a more troublesome ambiguity - is calc( 1 * 1px / 1em )
a "length" (number treated as length-like) or a "number" (number treated as raw number)?
Because of these ambiguities, I'm convinced that we must treat numbers as "number" type in calc(), always, and thus not allow adding them in 'line-height' and 'tab-size'. But that then means that we have a hole in those two properties for no good reason, just because their original syntax used a <number>
rather than inventing a special-purpose <length>
unit. At some point we probably want to plug those holes, and add two new <length>
units for those.
(Tho not interchangeable with lengths, another place where we're using a <number>
instead of a unitted value is in 'flex-grow' and 'flex-shrink'. These should have been the fr
unit, if we'd caught the discrepancy in time.)