[css-fonts-5] font-size-adjust: auto

[litherum]

https://www.w3.org/TR/css-fonts-4/#font-size-adjust-prop

Currently, the grammar is none | <number>. However, forcing authors to explicitly pick a number seems gratuitous. Why not add an auto value that just an alias for whatever the aspect value is in the element's primary font?

[litherum]

I suppose we'd have to think about how cascading inheritance would work, if a child element has a different primary font. Does it use the value from its parent, or would the value be reset for this element? I can see good arguments on both sides.

[litherum]

@jfkthame

[fantasai]

@litherum I think by cascading you mean inheritance. :) We can solve that by having auto compute to a number.

I remember @dbaron describing font-size-adjust as essentially "lets you pick the font size by its ex-height, but in a backwards-compatible way". The readability of a Latin font being more related to its ex-height than its cap-height. Such an auto value would not provide that functionality, just provide ex-heght consistency for font-family changes.

p.s. It's a little unfortunate that such a generic syntax is relevant only to European writing systems: I can imagine other writing systems needing adjustment across font families also. So maybe maybe it would be good if the keyword were a little more explicit that it's operating on the x-height...?

[svgeesus]

Such an auto value would not provide that functionality, just provide ex-heght consistency for font-family changes.

Why so? It is simply doing

let aspect = font_size[0] / x_height[0];

and then for all fonts in the list after the first one

font_size[n] = x_height[n] * aspect;

p.s. It's a little unfortunate that such a generic syntax is relevant only to European writing systems:

It is, but that proposal (by Todd Fahrner) was made a long, long time ago. The Web was still proud of being 8859-1 instead of ASCII, and handling all (Western) European languages.

It was proposed just after the first WD of CSS2 in 1997 but made it into the next one in 1998:

Property name: 'font-size-adjust'
Value: z | none | inherit

z
This value refers to the ratio of em- to x-heights of the "first choice" font in decimal notation.

Notice it was automatically calculated, just as Myles is proposing.

The 1998 Proposed Rec had changed it to a number:

'font-size-adjust'
Value: <number> | none | inherit
Initial: | none

[jfkthame]

One reason (I guess) for font-size-adjust taking a number rather than an auto value is that this means it will behave consistently regardless of whether the author's first-choice font (from which the number would normally be derived) is actually present or not.

With auto, the aspect would be computed from whatever fallback happens to get used; it would then provide consistency across additional fallbacks, but might be quite different from what the author expected based on the primary font they had named.

An auto value would also mean, presumably, that if the primary font-family is a webfont, and hasn't yet finished loading, we can expect the size of any fallbacks that are being used (e.g. for content in other scripts) to change when the font-load does complete.

(I'm not necessarily against an auto value, just trying to think through its implications. The behavior it enables would be significantly different from what an explicit <number> provides.)

[tabatkins]

iirc, that's precisely the reason we didn't provide an 'auto' value, yeah - providing an explicit value (presumably matching your first font) ensures that the value doesn't change if your first font doesn't load.

[svgeesus]

Yeah, I agree an explicit number is more robust.

[dbaron]

So there was a previous proposal for font-size-adjust: auto which I proposed in 2010 [Edit: also see the thread following] and that was discussed a good bit in this August 2013 thread and I think then removed. I'd note that that proposal didn't use the first available font, but instead used the UA's initial font. Such an auto basis isn't so useful when developers specify absolute font sizes, but it seems like it could be quite useful if the developer is using relative font sizes without resetting the UA's default to a length. I was also (see my initial proposal) hoping it could be useful for replacing the monospace font size preference hacks.

[litherum]

@svgeesus

Yeah, I agree an explicit number is more robust.

I don't understand why. Yes, with auto, the size of fallback fonts will change if the primary font changes. I think that's a feature, not a bug. Authors would opt-in to this behavior by specifying auto.

Possibly related: I'm not proposing changing the initial value.

[faceless2]

Related: https://github.com/mathml-refresh/mathml/issues/225