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)

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?

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.

@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.

Blink uses almost similar values

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

@kojiishi 1 is what unit? :)

@kojiishi 1 is what unit? :)

CSS pixels.

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

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.

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.

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.

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

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

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?

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

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

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?

@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.

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

@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.

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?

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.

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

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.

@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?

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.

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.

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).

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.