When marking up a web page featuring text that requires superscripts or subscripts, we should use the semantically meaningful <sup> and <sub> elements. Examples include footnote references⁽¹⁾ and simple maths 12₁₀=C₁₂.

When browsers come across <sup> and <sub> elements, their user agent stylesheet usually applies rules like this:

sub { 
  vertical-align: sub;
  font-size: smaller;
  line-height: normal;
}

This makes the text smaller and shifts the baseline up or down. There’s two downsides to this. The first is that the baseline shift usually causes anomalous line spacing, that is to say lines are pushed up or down to make space for the sub- or superscript. Secondly the sub/superscripted characters look slightly off – effectively their font weight has been reduced compared with the surrounding text.

Many OpenType fonts ship with properly designed sub- and superscripts. These are specifically designed for the purpose – the glyphs are already small (no change in font size required), retain a comparable weight and have a different shape compared with regular characters, as befits a thoughtfully shrunk down glyph. Even if these characters are available in the current font, browsers will ignore them and continue to synthesise using CSS properties. There are sensible reasons for this, as we shall see.

It is very easy to get browsers to swap in the OpenType glyphs instead – just use the font-variant-position property. For browsers which support it (all modern ones) you can override the user agent stylesheet and implement font-variant-position as follows:

@supports ( font-variant-position: sub ) {
  sub {
    vertical-align: baseline;
    font-size: 100%;
    line-height: inherit;
    font-variant-position: sub;
  }
}

But there’s a potential problem. What happens if the characters in the text you need to superscript are not all available as OpenType alternates in the current font? According to the CSS Fonts Module Level 4 specification, browsers should synthesise the whole superscript, even if some characters are available as proper superscripts:

Because of the semantic nature of subscripts and superscripts, when the value [of font-variant-position] is either sub or super for a given contiguous run of text, if a variant glyph is not available for all the characters in the run, simulated glyphs should be synthesised for all characters using reduced forms of the glyphs that would be used without this feature applied.

Phew. Job done. You’d have thought. Unfortunately at the time of writing only Firefox supports this behaviour; WebKit and Chromium do not. If the webfont has loaded, the font you are currently reading contains the following superscript alternates: ^0123456789(). That is to say no letters or other characters except the numbers 0–9 and a pair of parentheses. Now let’s consider the following markup:

2a<sup>2</sup> a<sup>2a</sup> a<sup>(2)</sup>
a<sup>(2a)</sup> a<sup>[2]</sup>

The superscripts vary, in that some of them contain characters which are all available, and others contain a mixture. The text should render like this:

This is how it renders in the browser you are currently using:

The chances are that none of the ‘a’s or square brackets are superscripted at all. I’ve filed this as a bug in Chromium and Webkit. I’ve also asked that font-variant-position be removed from Baseline until these bugs are fixed, as support is evidently incomplete, but also because that lack of support is harmful to the visual semantics, in other words it could change the intention and meaning of the text.

Finally I’ve proposed that full support for font-variant-position is included in Interop 2025. If you want to see this happen give my proposal some love.