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

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?

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:

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

@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

@kojiishi 1 is what unit? :)

@kojiishi

@kojiishi 1 is what unit? :)

CSS pixels.

@fontface

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

<dael> Topic: [css-inline-3] vertical-align: super and font metrics
<dael> github: https://github.com//issues/5225
<dael> fantasai: Maybe should have Jonathan.
<dael> fantasai: 3 questions on this.
<dael> fantasai: Background is current impl of super and sub are not dependent on font metrics, use UA text ratio
<dael> fantasai: Second point is there are font metrics for super and sub script. Third point is they are not particuarly reliable
<Rossen_> q
<dael> fantasai: Should spec allow, disallow, or require using font metrics? Require I don't think we can do reasonably
<dael> dbaron: Gecko seems to use font metrics.
<dael> 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
<dael> fantasai: Spec allows but doesn't require it. If that's fine leave spec as-is
<dael> Rossen_: That'll satisfy the halfway solution dbaron described or the full solution
<dael> dauwhe: There are places css is used which are not browsers which would be pleased to use font information
<dael> 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
<dael> dbaron: Dug in further. WE hard code these to 0.2 x em height for sub and similar for super.
<dbaron> https://searchfox.org/mozilla-central/search?q=_OFFSET_RATIO&path=&case=false&regexp=false
<dbaron> s/similar/0.34/
<dael> 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?
<dael> fantasai: If not using font metrics should we add an ability to do so?
<dael> heycam: Saw proposal about overriding metrics in @fontface rule
<dael> faceless2: That was myles. If solving solve for all.
<dael> 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.
<dbaron> or more precisely, https://searchfox.org/mozilla-central/search?q=NS_FONT_%5BA-Z%5D*_OFFSET_RATIO&path=&case=false&regexp=true
<dael> 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
<florian> [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]
<dael> 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
<dael> fantasai: Ratios aren't consistent but close
<dael> fantasai: One option is we could allow font metrics, don't require, try and get alignment on the ratios.
<dael> fantasai: Then explore having the metrics spec via @fontface
<dael> faceless2: Solving without solving for superscript size is doing half the job
<dael> fantasai: That's against Fonts 5
<dael> fantasai: You want to file it?
<dael> faceless2: I think it's best solved in fontface rule
<dael> 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.
<dael> faceless2: Yeah. I'll put a note
<dael> fantasai: Prop leave spec with a may, look into asking impl to align on fallback ratio, allow investigation of descriptors via font face
<dael> 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
<dael> fantasai: Seems like
<dael> 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
<dael> fantasai: Author can always use explicit length or %. If they wanted something precise they can do that
<dael> Rossen_: Anyt time we define anything as may we define may have problem for authors
<dael> 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.
<dael> fantasai: Maybe suspend until myles gets back
<dael> 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
<dael> fantasai: If you want to propose text that's fine
<dael> florian: I'll do that and run by myles
<dael> Rossen_: We can record resolution, myles can read and reopen when he comes back.
<dael> Rossen_: Progression of fantasai suggestions makes sense. Can't disallow so we need at least a may
<dael> Rossen_: Aligning on ratios that are as interop as possible is great.
<dael> 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.
<dael> Rossen_: First resolution should be leave vertical-align super and sub as a may
<dael> Rossen_: Objections?
<dael> RESOLVED: Leave vertical-align super and sub as a may
<dael> Rossen_: I don't know that we can have a resolution about ratios without actual ratios
<dael> fantasai: Yeah
<dael> Rossen_: Leave that open
<dael> fantasai: Okay
<dael> Rossen_: Last one is with @fontface
<dael> fantasai: I think font face descriptor for metrics should incl super and subscript size and position and allow opting in to use font metrics
<dael> Rossen_: Sounds good. Objections or comments?
<dael> RESOLVED: font face descriptor for metrics should include super and subscript size and position and allow opting in to use font metrics

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

@litherum

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

[css-inline-3] sub/super font metrics are a MAY; define fallback rati…

@litherum

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

@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

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

(I'm working on some of Gecko's inline layout code and was interested in this.)

I tracked down WebKit's + 1px on the sub/super ratios to see if there was anything indicating the purpose. It was introduced in KHTML in the pre-WebKit days in 2001:

5/3/2001 - e0234714 - Introduces support for vertical-align: sub/super using 1/5 for both.
5/4/2001 - 2ca6dbfc - Updates the calculations to 1em/5 + 1px and 1em/3 + 1px.

Nothing in the commit message to indicate why the additional pixel. I'm guessing it probably just looked better in their tests at the time.

Given the long history of WebKit's and Blink's additional pixel, and the fact that Gecko will have needed to adjust anyway (0.34 → 1/3), I wonder if standardizing to WebKit's calculation makes more sense.

Navigation Menu

Repository navigation

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

11 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

faceless2 commented on Jun 17, 2020

fantasai commented on Jul 20, 2020

dbaron commented on Jul 28, 2020

fantasai commented on Jul 28, 2020

kojiishi commented on Jul 28, 2020

fantasai commented on Jul 28, 2020

kojiishi commented on Jul 28, 2020

css-meeting-bot commented on Jul 28, 2020

11 remaining items

litherum commented on Jul 30, 2020

astearns commented on Jul 30, 2020

fantasai commented on Aug 13, 2020

litherum commented on Aug 29, 2020

astearns commented on Aug 29, 2020

litherum commented on Aug 29, 2020

fantasai commented on Aug 29, 2020

litherum commented on Aug 29, 2020

astearns commented on Aug 29, 2020

frivoal commented on Aug 29, 2020

litherum commented on Aug 29, 2020

kbhomes commented on Jan 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions