[css-fonts-4] [varfont] font-stretch should accept <number> to support calc()

[bramstein]

The current draft for variable font support defines font-stretch to accept the following values:

normal | ultra-condensed | extra-condensed | condensed | semi-condensed | semi-expanded | expanded | extra-expanded | ultra-expanded | <percentage>

Even though <percentage> may seem like a natural fit (and even suggested by the OT variable font spec), it excludes the use of calc() to dynamically calculate a value along the wdth axis.

There have been several attempts at using a condensed typeface at narrow viewports (most notably on A List Apart). It is plausible that web developers will want to dynamically calculate a value for font-stretch, so <number> seems more appropriate to me (though as a work around, the lower level font-variation-settings could also be used).

[bramstein]

Alternatively, font-stretch could also accept <number> in addition to <percentage>.

[litherum]

getComputedStyle() should probably return the percentage, though (if the number supplied is arbitrary and not in the keyword table)

[fantasai]

Seems reasonable to me. calc() users can always multiply by 100%, so this would really be more of a convenience.

[fantasai]

It might be worth checking in on other places where we use percentages while we're thinking about this.

[svgeesus]

I agree that with variable fonts, it is more natural to specify a number than to be restricted to a quantized set of keywords or be forced to use the low-level font-variation-settings.

[tabatkins]

I don't understand - what is the benefit of number over percentage? What problem does percentage cause?

[tabatkins]

(If it's the bug in the calc() spec that means calc() isn't allowed to resolve to a bare <percentage>, but it can resolve to a <number>, that's a bug for us to fix. Other specs shouldn't work around it.)

[litherum]

According to https://drafts.csswg.org/css-values-3/#calc-notation

[calc] can be used wherever ... <percentage> ... values are allowed.

<calc-value> = <number> | <dimension> | <percentage> | ( <calc-sum> )

So there's no reason why calc(20% * 3) wouldn't work.

[tabatkins]

Ah, so we did fix that, good. ^_^