[csswg-drafts] [css-values] Problematic missing length units for 'line-height' and 'tab-size'

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

== [css-values] Problematic missing length units for 'line-height' and 'tab-size' ==
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.)

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

Received on Thursday, 25 May 2017 08:09:17 UTC