[css-fonts] font-variant-numeric: diagonal-fractions, in most fonts, doesn't work with semantic markup

[jyasskin]

The https://drafts.csswg.org/css-fonts/#steak-marinade example applies font-variant-numeric: diagonal-fractions to semantically-meaningful spans in a way that doesn't work with most actually-existing fonts.

Specifically, when the frac feature is turned on, all but one of the fonts I can find do one of two things. Extending the example above:

<link href="https://fonts.googleapis.com/css2?family=Ubuntu+Mono&display=swap" rel="stylesheet">
<link href="https://fonts.googleapis.com/css2?family=IBM+Plex+Sans&display=swap" rel="stylesheet">
<style>
  @font-face {font-family:'GimletDisplay Light'; src:url('https://www.axis-praxis.org/fonts/webfonts/Gimlet_Romans-VF.woff2');}

  .amount { font-variant-numeric: diagonal-fractions; }
</style>

<p><span class="amount">1 3/4</span> C. sugar</p>
<p><span class="amount">13/42</span> tbs. salt</p>

1. They format every digit as a numerator unless it follows a /, at which point it's formatted as a denominator.

  p {font-family: "IBM Plex Sans";}

The "Times New Roman" and "Arial" fonts used as the default serif and sans-serif fonts on Windows 10 have this behavior.

2. They special-case certain substrings to format as small fractions, but break the rendering of a larger fraction that happens to contain that substring.

  p {font-family: "Ubuntu Mono";}

I did find one font that behaves sensibly, so the feature is possible:

  p {font-family: "GimletDisplay Light";}

I'm not sure of the right thing for the WG to do at this point. A couple options might be:

1. Change the example to use formatting-markup instead of semantic-markup: something like

   <li>1 <span class="fraction">1/2</span> tbsp dry minced onion</li>

   This is probably safe as long as people only mark up a single digit on each side of the /. With more than one digit included, fonts like Ubuntu Mono will break things.
2. Deprecate diagonal-fractions: if it's not usable in semantic markup, does it deserve a place in font-variant-numeric? It'd still be accessible through font-feature-settings: "frac".
3. Go talk to font designers and encourage them to do whatever Gimlet is doing.

[svgeesus]

Thanks for the clearly documented issue. The only things that is missing is what OpenType features are present in each of the fonts in your examples. Did you check this? A convenient way to do so, if you don't have font editing software to hand, is to use Wakamai Fondu – just drag a font there (it is processed locally, not sent to a server, so does not infringe any font license) and get a report of (among other things) all the OT features.

Because, as you say, if Gimlet behaves correctly then it is doing something different to the others listed.

Note that the frac feature is defined in terms of two other features, numr and dnom and speaks of the span of characters over which this feature has been applied by the user which imlies tight wrapping is preferred.

<span class="fraction">22/7</span>

doesn't seem un-semantic, to me. For example, it could be styled various ways to indicate that it is a fraction.

[bungeman]

It is interesting taking a look at these fonts.

A number of fonts like Arial, Times New Roman, and IBM Plex Sans seem to implement frac as described at https://ilovetypography.com/OpenType/opentype-features.html. This results in all digits being superscripted unless they follow a / in which case they are subscripted (so digits are never left as normal).

Fonts like Ubuntu Mono are essentially implementing frac as (very) finite set of ligatures. Such fonts should at least make sure these ligatures don't have more digits on either side (not doing so is just a bug in the font).

The Gimlet font from the original example does a rather verbose set of chain context matches (GSUB LookupType 6.2) to match the leading digits (essentially writing everything out explicitly in an n^2 way). It implements this out to 10 iterations, so the numerator is limited to 10 digits (any additional digits before the / will not be made superscript). It looks like an unlimited number of trailing digits will be made subscript, however.

I'm not sure but maybe fonts could use GSUB LookupType 8.1, though I haven't actually tried that. And this should work with AAT. In any event, many popular fonts don't handle frac in a super general way, so it's probably best to discourage non-targeted use.

[jyasskin]

I'm assuming Ben's comment covers "what OpenType features are present".

I'd like the normative wording, possibly including both CSS and OpenType changes, to wind up being clear

1. For each font-variant value, what glyph spans it makes sense for authors to apply the value to (e.g. don't try <span class="fraction">4,321/2,345</span> either), and
2. That Ubuntu Mono and similar fonts are out of compliance, which might encourage UAs to disable the feature for a special-cased list of fonts.

Does that make sense? Basically, ensure that authors can use the font-variant-* properties without investigating the detailed behavior of every font in their fallback list including the user-configured generic families.

[svgeesus]

I contacted David Jonathan Ross, creator of Gimlet, with a pointer to this issue in case they had time to comment. David wrote:

As far as the fractions go, I believe that Gimlet more-or-less follows Tal Leming’s approach to fractions, detailed at his OpenType Cookbook. It’s not a perfect system, but it handles mixed fractions nicely, even if I can’t tell the difference between fractions and dates (12/2). You can see more information on his old website and on the Glyphs app page about fractions, if helpful.

[svgeesus]

That Ubuntu Mono and similar fonts are out of compliance

The documentation in the OpenType specification for this feature is sufficiently brief and vague that such fonts are probably not out of compliance. There is an illustrative example of a non-standard fraction (ie not one which is separately encoded in Unicode) but that is all.

CSS Fonts 4 does at least give an example of an integer followed by a fraction, which raises a slightly higher bar by example.

A good place to discuss improving the OpenType specification would be the Font and Text CG

[jyasskin]

Thanks for the pointer @svgeesus; I've filed an issue there.

[jyasskin]

I'm not sure if this should be a separate issue, but: given that fonts vary a lot, the Font and Text CG closed without handling this issue, and CSS automatically falls back to different fonts if the developer's preferred font doesn't load, it seems like the font-variant-*, font-feature-settings, and similar properties should avoid applying to fallback fonts. Otherwise, if I've marked up <frac>1 1/2</frac> to get Lato's (approximately) "1 ¹⁄₂", I might instead get the fallback font's "¹ ¹⁄₂".

I could imagine either specifying which font(s) each property applies to, or just saying that they only apply to the first element of the font-family list.

[Crissov]

One popular place that might benefit from a more refined definition in either CSS or OT is Wikipedia’s {{frac}} template, which currently generates HTML code like this:

<span class="frac" role="math"
>12<span class="sr-only"
>+</span><span class="num"
>34</span
>&frasl;<span class="den"
>56</span></span>`

It then synthesizes the desired look with some style like this:

.frac {
	white-space: nowrap;
}
.frac .num,
.frac .den {
	font-size: 80%;
	line-height: 0;
}
.frac .num {
	vertical-align: super;
}
.frac .den {
	vertical-align: sub;
}

The template has always output U+2044 Fraction Slash.
Replacing <span class="sr-only">+</span> with U+2064 Invisible Plus has been discussed but rejected; earlier versions used a (narrow?, non-breaking?) space character there.
It was also (ab)using <sup> for numerator and <sub> for denominator until a couple of years ago.
Replacing some recognized vulgar fractions with precomposed ligature characters like ⅔ was also considered but rejected.

This template is, arguably, also supposed to work with more complex cases, e.g.:

• 1234⁄56789
  • 1.234⁄56.789
  • 1,234⁄56,789
  • 1’234⁄56’789
  • 1'234⁄56'789
• π⁄3
  • 2π⁄3
  • 2*π⁄3
  • 2·π⁄3
  • 2⁢π⁄3 Invisible Times
• 1⁄√2 Radical Symbol
• 1⁄2n
  • 1⁄2⁢n
• 1⁄<var>n</var>
• km⁄h, €⁄kg
• २⁄३
• ۲⁄۳
• (The spacing after, as in 2⁄3 π, is out of scope.)

It would be informative to know whether authors could ever expect font-variant-numeric: diagonal-fractions and stacked-fractions to work with any fractions like these, which go beyond simple digits [0123456789], when using U+2044 or when using U+002F Solidus.
Vulgar fraction units are probably out of scope as are (single-)letter constants and variables, but local digits (like the Devanagari and Arabic examples above) are perhaps in scope. I’m not sure about things like the square root symbol.