[css-inline-3] vertical-align: super and font metrics

[fantasai]

We currently encourage UAs to use the parent font's metrics when positioning a superscript or subscript using vertical-align, but it doesn't seem like browser implementations, at least, do that. And I'm guessing making such a change would have noticeable Web-compat implications.

Should we introduce additional keywords, like font-super / font-sub or an additional use-font keyword to allow for using font metrics?

[faceless2]

The metrics from the font are OS2 table values ySubscriptYOffset and ySuperscriptYOffset. They're ignored, and our testing notes have "Firefox uses 0.34em and -0.2em, Safari 0.333em and -0.2005em"

Another possibility is to incorporate this into #4792 - you could have

@font-face {
    font-family: ...
    superscript-position: auto;
    subscript-position: from-font;
}

where auto is current behaviour, from-font is strictly from the font OS2 table, or an absoute value could be specified.

I can see you're working through a lot of font metrics issues at the moment, which is great - I think many of them could be solved by implementing #4792

(earlier comment on this issue by me was posted too soon due to fat fingers - I deleted it)

[fantasai]

So sounds like we have a few questions here with a few options each:

1. Should the spec allow (MAY) / disallow (MUST NOT) using font-metrics for vertical-align: super | sub? (Require is likely a non-starter given both Web-compat and bad font metrics, so not listing that theoretical option.)
2. Should the spec dictate the ratios for superscript/subscipt shifts that are not derived from font metrics so that we have inteop? If so, what ratios should it require?
3. Should we add some way to have vertical-align use the font metrics? If so, should it be via keyword on vertical-align or via descriptor on @font-face?

[dbaron]

For what it's worth Gecko's layout code thinks it's asking for the font metrics, but the font code uses a constant. Note that that constant is separately used by the code that handles font-variant-position.

[fantasai]

@dbaron ... that seems bad. I think font-variant-position should definitely be using the font metrics if they exist, since it's supposed to try to match against actual glyphs in the font.

[kojiishi]

Blink uses almost similar values

• sub = font-size / 5 + 1
• super = font-size / 3 + 1

[fantasai]

@kojiishi 1 is what unit? :)

[kojiishi]

@kojiishi 1 is what unit? :)

CSS pixels.

[css-meeting-bot]

The CSS Working Group just discussed [css-inline-3] vertical-align: super and font metrics, and agreed to the following:

• RESOLVED: Leave vertical-align super and sub as a may
• RESOLVED: font face descriptor for metrics should include super and subscript size and position and allow opting in to use font metrics

The full IRC log of that discussion

Topic: [css-inline-3] vertical-align: super and font metrics
github: https://github.com//issues/5225
fantasai: Maybe should have Jonathan.
fantasai: 3 questions on this.
fantasai: Background is current impl of super and sub are not dependent on font metrics, use UA text ratio
fantasai: Second point is there are font metrics for super and sub script. Third point is they are not particuarly reliable
q
fantasai: Should spec allow, disallow, or require using font metrics? Require I don't think we can do reasonably
dbaron: Gecko seems to use font metrics.
dbaron: Cross platform code calls into font metrics code to get super and subscript metrics. I haven't looked into specifics of what they return
fantasai: Spec allows but doesn't require it. If that's fine leave spec as-is
Rossen_: That'll satisfy the halfway solution dbaron described or the full solution
dauwhe: There are places css is used which are not browsers which would be pleased to use font information
florian: Source of concern. THat it should be accessible, yes. If you can get that with a keyword that does something different in browsers is not great
dbaron: Dug in further. WE hard code these to 0.2 x em height for sub and similar for super.
https://searchfox.org/mozilla-central/search?q=_OFFSET_RATIO&path=&case=false®exp=false
s/similar/0.34/
fantasai: So question is do we want to allow browsers or impl to use font metrics? If we're not requiring do we want to require a ratio and get interop? If we're disallowing should we spec a ratio?
fantasai: If not using font metrics should we add an ability to do so?
heycam: Saw proposal about overriding metrics in @fontface rule
faceless2: That was myles. If solving solve for all.
AmeliaBR: Have a feature in font variant that allows proper typographic sub and super from font. So is a way to access if you have a well defined font. hAven't played with it.
or more precisely, https://searchfox.org/mozilla-central/search?q=NS_FONT_%5BA-Z%5D*_OFFSET_RATIO&path=&case=false®exp=true
fantasai: That one will pull out glyphs and synthesize them if font doesn't have. Doesn't shift baseline so if you have nested super or an image as a super that's not a pure glyph you cannot do that
[more info on using font-variant for that sort of things at https://wiki.csswg.org/faq#styling-sup-and-sub-using-font-variant-position]
AmeliaBR: As an author it would be useful to be able to have vertical-align:super do something nice and typographic but I'd be very worried about backwards compat if we widely change the standard html 1 subscript style
fantasai: Ratios aren't consistent but close
fantasai: One option is we could allow font metrics, don't require, try and get alignment on the ratios.
fantasai: Then explore having the metrics spec via @fontface
faceless2: Solving without solving for superscript size is doing half the job
fantasai: That's against Fonts 5
fantasai: You want to file it?
faceless2: I think it's best solved in fontface rule
fantasai: But you haev to be able to access the size. vertical-align is only about baseline position. If you want to be able to size it you have to add to fonts 5.
faceless2: Yeah. I'll put a note
fantasai: Prop leave spec with a may, look into asking impl to align on fallback ratio, allow investigation of descriptors via font face
florian: Question, what we expect impl to do with the may is by default link to a fixed ratio and have an allow list of fonts with useful metric and use that if someone particularly cares about typography
fantasai: Seems like
florian: If we don't get guidance I wonder if people won't start to use metrics from fonts or cause more problems where I put something which looks wrong in Chrome and I corrected
fantasai: Author can always use explicit length or %. If they wanted something precise they can do that
Rossen_: Anyt time we define anything as may we define may have problem for authors
florian: Seems safe if we assume default is ratio and you opt in to better if it's that it's fine. If it applies in bad fonts for some browsers it will be weird.
fantasai: Maybe suspend until myles gets back
florian: I'm hinting at it's fine but adding a note what the may is for and that people should be careful when impl
fantasai: If you want to propose text that's fine
florian: I'll do that and run by myles
Rossen_: We can record resolution, myles can read and reopen when he comes back.
Rossen_: Progression of fantasai suggestions makes sense. Can't disallow so we need at least a may
Rossen_: Aligning on ratios that are as interop as possible is great.
Rossen_: Already a number of posts in issue from impl that desc how they get ratios. Encourage more of that so we can come down to something same.
Rossen_: First resolution should be leave vertical-align super and sub as a may
Rossen_: Objections?
RESOLVED: Leave vertical-align super and sub as a may
Rossen_: I don't know that we can have a resolution about ratios without actual ratios
fantasai: Yeah
Rossen_: Leave that open
fantasai: Okay
Rossen_: Last one is with @fontface
fantasai: I think font face descriptor for metrics should incl super and subscript size and position and allow opting in to use font metrics
Rossen_: Sounds good. Objections or comments?
RESOLVED: font face descriptor for metrics should include super and subscript size and position and allow opting in to use font metrics

[fantasai]

Suggestion based on the impl data above (thanks everyone!): Make the ratios be -1em/5 for subscripts and 1em/3 for superscripts. This will be a slight shift for all implementations, but should be pretty close.

[frivoal]

I suggest adding something like the following:

Note: Deriving the offset for subscripts and superscripts from font metrics leads to better typography when these metrics have been correctly set by the creator of the font. Unfortunately, they often aren't. To avoid bad results—for which authors might end up compensating manually, in non-necessarily interoperable ways—implementations are encouraged to only derive the offset for subscripts and superscripts from font metrics for fonts known to the implementer to have usable metrics, and to use a fixed ratio otherwise.

[faceless2]

It feels like giving authors the ability to use font metrics for super/subscript position, without giving them the option to use font-metrics for super/subscript size, is solving only half the problem. OpenType has fields for both superscript and subscript size, so in theory they could differ.

The only solution I can see for this is adding font-size: superscript and font-size: subscript.

[css-meeting-bot]

The CSS Working Group just discussed https://github.com/w3c/csswg-drafts/issues/5225, and agreed to the following:

• RESOLVED: 0.2em and 1/3 em are the ratios for super and sub script

The full IRC log of that discussion

topic: https://github.com//issues/5225
github: https://github.com//issues/5225
fantasai: [lists ratios used by each browser]
fantasai: All slightly off but fairly close
fantasai: I prop 0.2em and 1/3em and put that is spec
florian: +1px seems very specific
koji: I checked commit log and added hyatt. So it's old code
florian: In that case sure
fantasai: Prop 0.2em and 1/3em. Slightly different but very close for everyone
Rossen_: Thoughts or objections?
koji: Do we have myles?
Rossen_: 12 more minutes
fantasai: Safari is using 0.2005 and 1/3em
smfr: That was me measuing on screen so not gospel
s/smfr/faceless2/
Rossen_: As any other decision we can change our minds
Rossen_: Would be reasonable
Pretty sure smfr could give gospel answer!
Rossen_: Objections to 0.2ema nd 1/3 em are the ratios for super and sub script?
RESOLVED: 0.2em and 1/3 em are the ratios for super and sub script

[litherum]

WebKit would be willing to try to use the parent font's metrics in WebKit (and see how it goes).

[litherum]

I don't understand the resolution:

RESOLVED: 0.2em and 1/3 em are the ratios for super and sub script

Ratios of what? font size? amount to raise/lower the line for sup/sub? Something else?

[faceless2]

0.2em was the amount to shift down for vertical-align: sub, 1/3em was the amount to shift up for vertical-align: super

[litherum]

RESOLVED: font face descriptor for metrics should include super and subscript size and position and allow opting in to use font metrics

I agree with @faceless2:

faceless2: If solving solve for all.

I think we should revisit this resolution in light of #4792

[litherum]

https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/rendering/RootInlineBox.cpp#L1041

        if (verticalAlign == VerticalAlign::Sub)
            verticalPosition += fontSize / 5 + 1;
        else if (verticalAlign == VerticalAlign::Super)
            verticalPosition -= fontSize / 3 + 1;

RESOLVED: 0.2em and 1/3 em are the ratios for super and sub script

Is the intention for this resolution to document what browsers are already doing, or was the intention of this resolution to cause browsers to change their behavior?

[astearns]

@litherum a bit of both. It was observed that browsers were using hardcoded ratios, but slightly different ones. So documenting the use of a ratio, and have browsers change behavior to use the same ratio.

[litherum]

I'd like to propose loosening the spec to allow for the + 1 that we're doing today.

[astearns]

@litherum if there’s a good reason for the +1 I would prefer that we just use that. We wondered why it was there in the discussion, but did not find an answer.

[fantasai]

Edits are in, so I want to close this issue. (Handling font metrics explicitly provided by CSS is a problem for the day after we actually spec that feature. Of course those should be honored, but they don't exist atm so I can't spec honoring them.)

@litherum did you want to argue for standardizing the +1px? It's kinda weird, no?

[litherum]

I don't want to argue for standardizing the +1. I do want to argue for allowing browsers to include a +1 if they choose.

[astearns]

@litherum would it work then to open a new issue with that request, outlining your reasons why?

[litherum]

The "why" is just "it isn't necessary to change behavior here." We can't just go around changing the positioning of text just because it makes mathematical formulas simpler.

[fantasai]

@litherum We do try to improve interop, though, unless there's a reason to allow divergent behavior. So, why should we allow divergent behavior here, rather than all using the same formula?

[litherum]

I think I’d flip that around. Does the flexibility to increase the formula by 1px break websites? Clearly not, because WebKit is an existence proof.

[astearns]

I don’t agree with the flip. There are plenty of places where we choose a value/formula/algorithm to use, and only very reluctantly agree to variations because there are places where we are concerned it would break web content.

In this case we agree there’s no concern about breaking web content, because everyone is using different formulas now. It’s an improvement to switch to a single formula. It’s less of an improvement if we allow the +1 variation, so that has to be justified.

[frivoal]

I'm not terribly enthusiastic about multiple variation either, but I don't see a huge issue on everyone aligning on 1em/3+1px, 1em/5+1px instead of 1em/3, 1em/5.

Having a rationale for the +1px would be good, but even if there isn't really one, the fact that blink and safari are already both on the +1 version could be sufficient. Then among browsers it's only Firefox that needs to change (and it needed to change anyway).

[litherum]

I don’t agree with the flip. There are plenty of places where we choose a value/formula/algorithm to use, and only very reluctantly agree to variations because there are places where we are concerned it would break web content.

From a browser developer’s point of view, the flip is relevant. The CSSWG is proposing that browsers make a behavior change, and for what? Will it be a progression? I agree it would cause browsers to match each other more closely, but you have to remember that way more users use the same browser over time (multiple releases) than who use multiple browsers at the same time.

And from an author’s point of view, they just asked “please make this text sup.” They didn’t specify an exact pixel offset. If superscript positions are 1px different in some browsers, does that break their content? Seems unlikely.

So from a user’s point of view, the risks outweigh the benefits, and from an author’s point of view, they probably don’t care about this specific 1px difference in these specific formulas. I don’t agree that standardizing things just for standardization’s sake is the right thing to do in every case.

I don't see a huge issue on everyone aligning on 1em/3+1px, 1em/5+1px instead of 1em/3, 1em/5.

This would be a reasonable path forward. I can try to dig up the rationale for the +1px.