@font-face overrides for superscript/subscript metrics

[fantasai]

In #4792 we resolved to accept @font-face descriptors for overriding the ascent/descent metrics. In #5225 @litherum suggested also adding metrics for superscripts and subscripts.

The proposal then would be to add:

• superscript-shift-override, affecting vertical-align: super and font-variant-position synthesis
• subscript-shift-override, affecting vertical-align: super and font-variant-position synthesis
• superscript-size-override, affecting font-variant-position synthesis (and maybe some future super keyword for font-size, if we end up going there)
• subscript-size-override, affecting font-variant-position synthesis (and maybe some future sub keyword for font-size, if we end up going there)

See https://www.w3.org/TR/css-fonts-4/#font-variant-position-prop for an illustration of how these metrics are used for superscript and subscript glyph synthesis.

[chrishtr]

As I understand it from re-reading the notes from last week (*), the motivation for superscript/subscript is that font metrics in font files are often wrong (whereas for some of the other font metrics overrides, it's an issue of lack of interop across browsers, or a desire to minimize layout shifts during WebFont loading.

If it's just that font metrics in font files are often wrong, would it make more sense to get the fonts themselves fixed rather than adding developer workarounds? Are there certain cases where it is impractical to ever get the fonts fixed?

(*) Snippets:

fantasai: Briefly, font has metrics on amount to shift up/down for
super/subscript and says what size as function of font
size. If font provides a glyph it's supposed to provide
ones that match. If you don't have glyph UA can synthesize
by resizing. In order to get that to match you need
metrics and a lot of fonts don't have
chrishtr: Is there difference between OS and browsers?
fantasai: No, font metrics are frequently wrong
chrishtr, see example in
https://www.w3.org/TR/css-fonts-4/#font-variant-position-prop
Rossen: This is very much related but I would prefer we open a new
issue where more thought can be given. fantasai can you open
that?
fantasai: Yep

[litherum]

As far as I can tell, the canonical definition of vertical-align is in CSS2.1, where it says:

sub
Lower the baseline of the box to the proper position for subscripts of the parent's box. (This value has no effect on the font size of the element's text.)
super
Raise the baseline of the box to the proper position for superscripts of the parent's box. (This value has no effect on the font size of the element's text.)

It doesn't appear to define what "proper position" means.

I believe that this means that WebKit's (and probably other browsers') behavior of disregarding what the font says and just using a hardcoded formula to determine vertical-align: sub and vertical-align: sup is spec-compliant.

If this proposal for superscript-shift-override and subscript-shift-override were to be accepted, would this hardcoded formula become noncompliant, even if the descriptors were present? (Another way of asking this question is: would this spec change be a must or a should or a may?)

[litherum]

Nitpick on the naming: The TrueType and OpenType specs both call this "position" instead of "shift".

[fantasai]

@litherum Wrt hardcoded formulas, I think what would make sense is if the descriptor is supported, then the UA MUST use that value (instead of the hardcoded value or the value in the font that it would otherwise have used). If the descriptor is not supported, then obviously that requirement doesn't apply. "Supporting" the descriptor and not honoring it for vertical-align makes no sense.

Wrt naming, I wanted to be consistent with the CSS property baseline-shift (whose name we inherited from XSL:FO via SVG and can't change). The font-variant-position property encompasses both sizing and shifting operations--and of course position has other meanings as well in CSS--so I don't think it's a better fit.

[kojiishi]

By reading conversation, I wonder maybe we don't understand the proposal correctly. Can someone help us to understand what this proposal include?

In the original description and from the minutes of the weekly call, I can read:

• Ability to override size/position of superscript/subscript in the font.
• The font-variant-position property uses these metrics from the font.
• The motivation to override is that values in the font are frequently wrong.

Then @litherum is talking about the vertical-align property, which IIUC we agreed to use the hard coded values. How is this connected to the proposal? Did we miss a discussion to use these metrics for the vertical-align property somewhere?

[fantasai]

@kojiishi Yes, in https://lists.w3.org/Archives/Public/www-style/2020Aug/0006.html we resolved that css-inline-3 would allow the UA to use the font metrics for the sub/super positions. There was also an additional resolution to define the hard-coded values for the cases where the UA is not using font metrics so that we can have interop. Using font metrics is optional because of concerns about back-compat and whether the metrics are reliable; but if the author is providing them explicitly in an @font-face rule, neither of those concerns applies anymore so we should use the author's explicit metrics.

I think it's important for font-variant-position and vertical-align to agree on where the superscript/subscript baseline is so that superscripts/subscripts are positioned consistently even in cases where font-variant-position isn't powerful enough to position them and the author has to use vertical-align to do it.

[litherum]

I'm worried about "must" language requiring browsers to switch away from browsers' hardcoded formula in favor of data provided by the authors. It seems to me that bogus data can occur in CSS just as easily as it can occur in font files. (This proposal seems to be about fixing the problem of bogus data, as compared to ascent-override which is about fixing the problem of incompatible, but not bogus, data.)

However, a browser has the ability to ignore any property or descriptor if it believes doing so is in the interest of the user, regardless of whether or not the spec uses "must" language. It seems to me that, even if the spec says "must", if the webpage puts something crazy in there, the browser would still be within its rights to ignore it and use a hardcoded formula. This is already the case (i.e. "implementation limits") for many (all?) existing properties.

From an author's perspective, "must" language would probably be a good thing, as they want to provide some fairly strong signal that what they put in their CSS is actually going to be used (assuming they don't do anything crazy).

So I think I would be positive on using "must" language, like @fantasai proposed in #5518 (comment).

[kojiishi]

Thanks for the clarification. So we're discussing three topics IIUC.

Fixing bogus data in fonts

I think this should be discussed with #5542. As @plinss pointed out, there are more properties in the font where some fonts have bogus data. Are we going to say it's all authors' responsibility to fix all fonts in their CSS, or is there any reasons where superscript/subscript are different from x-height, cap-height, and all other properties?

Where this change apply

Thanks, so IIUC, in https://lists.w3.org/Archives/Public/www-style/2020Aug/0006.html

RESOLVED: Leave vertical-align super and sub as may use font metrics

but all browsers use a hardcoded formula today. Is this correct?

I don't have our position on this topic yet. IIRC whatwg tried to change <sup> and <sub> to use font-variant-position but they gave it up. We might want to investigate more before reaching to a conclusion.

Require to use metrics in vertical-align if overridden

I don't have our position on this topic yet either, but just want to confirm, so the proposal is to use authors' metrics if overridden, but we won't provide a way to use the metrics in the fonts? Isn't that against what you want?

[svgeesus]

@kojiishi wrote

IIRC whatwg tried to change <sup> and <sub> to use font-variant-position but they gave it up. We might want to investigate more before reaching to a conclusion.

They did, and IIRC we asked them not to, because font-variant-position uses the OpenType subs and sups features to enable the use of font-designer-created subscript and superscript glyphs instead of scaling regular glyphs. Where those glyphs exist, it gives a typographically superior result. For one level of subscripting or superscripting, only.

While HTML can have

<p><sub>Many<sub>levels<sub>of<sub>subscripting</sub></sub></sub></sub></p>

[frivoal]

IIRC whatwg tried to change <sup> and <sub> to use font-variant-position but they gave it up. We might want to investigate more before reaching to a conclusion.

See also https://wiki.csswg.org/faq#styling-sup-and-sub-using-font-variant-position

[litherum]

@kojiishi

the proposal is to use authors' metrics if overridden, but we won't provide a way to use the metrics in the fonts?

The grammar for these descriptors today is normal | <percentage>, where normal means "do whatever you're doing today." It would probably be natural to add a from-font value for the metrics which browsers don't usually take from the font.