[rhythmvs]

> “monospace fonts tend to be wider, so the default font size (medium) is scaled so that they have similar widths”

> “the base size depends on the font family and the language … Default system fonts are often really ugly for non-Latin- using scripts.”

‘often’, ‘tend to be’: I am worried. I think it’s a really bad idea to deflect default behavior based on such assumptions, certainly when the deviations are a blind process triggered by proxies (like language tags and some vaguely statistical rules-of-thumb for dealing with generic font family names). That is: without even looking at the actual design and metrics of the actual font involved.¹

What happens if the monospaced font in case has a normal x-height and/or an advance-width equal to that of its serif counterpart? What if the CJK and Devanagari fonts have characters drawn already ‘big on the body’?² Then such hard-coded default moonshot-fixes which try to cater for the lowest common denominator will make things needlessly hard to debug and force the designer still to ad-hoc size-adjust font per font, but now also trying to fix the browser’s ‘fixes’. (Too bad: any `normalize.css` wont help…³)

And yet, all of the needed data is available in the font file. There’s even a dedicated CSS property for dealing with fonts’ varying metrics: `font-size-adjust`.⁴ Not that browser makers care to implement⁵, but since the OP’s post concerns Firefox (which does support `font-size-adjust`, but the article does not discuss it) I wonder: is it a matter of performance that retrieving the actual font metadata and metrics is left out of the equation? Surely, the fact that local font files, base64 data-URI embedded or externally hosted ones can be used, makes implementation all but trivial…

At Textus.io⁶ we’re going great lengths to solve typographic issues such as these. Point in case: for each font we read out the `xHeight` value, then calculate the actual font-size relative to the font’s UPM (unitsPerEm), so we have consistent apparent font-sizes, c.q. aspect ratios.

I think it all boils down to a separation of concerns: proportion and interrelated sizes (ascender, caps, descender, x heights, stem width, etc.) are up to the discretion of the font designer, overall aspect size is the business of the typesetter (css stylesheet author), and the browser ought always draw consistently, regardless of generic font family name, language and/or Unicode code range.

¹ https://opentype.js.org/font-inspector.html ² https://medium.com/@xtianmiller/your-body-text-is-too-small-... ³ https://github.com/h5bp/html5-boilerplate/issues/724 ⁴ https://developer.mozilla.org/en/docs/Web/CSS/font-size-adju... ⁵ http://caniuse.com/#feat=font-size-adjust ⁶ http://www.textus.io

[ptx]

> I am worried ... really bad idea ... will make things needlessly hard to debug

It has worked this way since the days of Netscape Navigator[1], though, so it's not a change or a new idea. It's just keeping things the way they've always been. (Nowadays, in Firefox, the corresponding settings are under Preferences -> Content -> Fonts & Colors -> Advanced.)

[1] http://www.alanwood.net/unicode/mac_net6.gif

[rhythmvs]

That Netscape screenshot only shows users have always been able to specify their own font preferences for three generic font families (serif, sans-serif, mono), along with a respective font-size. I’m not objecting to that: in fact, it’s a Good Thing that users are able to take control.

But taking control also means dealing with inconsistencies myself. If I were so bold as to set Impact as my default serif font, then I would also set a considerably smaller font-size to make up for the huge x-height. The thing is: if it would bother me, I, as an end-user, could do so, thanks to the browser’s interface exposing to me the needed controls.

It’s a whole different thing when browsers would start changing default behavior based on ‘common’ properties in ‘most’ fonts, without inspecting the real features of the actual fonts they render. Different, because if it would bother me, as a web developer, I couldn’t do anything about it, because the browser, while deviating from standard defaults, would not offer me the required controls, i.e. would render my CSS rules differently based on opinionated variables I cannot know.

[hsivonen]

That screenshot is from Netscape 6—a Gecko-based Netscape release without “Navigator” in the name. The mechanism mostly survives in Gecko today except for the Latin unification (previously split to Western, Central European, etc.).

[ptx]

Oops! It was definitely there in Netscape 4, but I was a bit sloppy with the image search. Here is the Netscape 4 screenshot:

http://www.alanwood.net/unicode/mac_net472.gif

[Manishearth]

> And yet, all of the needed data is available in the font file. There’s even a dedicated CSS property for dealing with fonts’ varying metrics: `font-size-adjust`

These are web features from before CSS existed.

The whole font sizing thing comes from how `<font size=x>` used to behave. When CSS came it only complicated this. font-size-adjust is pretty new.

And once the web starts behaving a certain way it's kind of hard to "fix".

(Also, according to a comment on /r/rust, this seems to be something that is an intrinsic problem with monospace fonts, https://www.reddit.com/r/rust/comments/6swzl5/fontsize_an_un...)

(Also, just to mention, all of this complexity would still have to exist even if the monospace thing wasn't a problem, to support user configured font sizes)

> I wonder: is it a matter of performance that retrieving the actual font metadata and metrics is left out of the equation?

I think there is a nontrivial perf impact, yes. We've had to do some locking to make font metrics (for ex and ch) work in Stylo, for example, and while we've optimized it it still makes us lose out on parallelism a bit.

[chrismorgan]

I believe I’ve come across allegations that the metrics encoded in the font (xHeight and unitsPerEm, by the sound of it) are fairly hit-and-miss. Any comments on that?

Bear in mind non-Latin scripts also.

[rhythmvs]

Sure. Badly produced fonts (those you can find on the cheap), tend to have faulty metrics: i.e. the designer did not change the default ones of the font design app (Glyphs, FontLab, FontForge, &c.) they are using so as to match the actual outlines of the glyphs they drew.

E.g. the font’s metrics tell: xHeight=500 and UPM=1024, so we may assume the aspect ratio is 0.48. But then we look at the outlines and see the designer drew the upper most top node of the x at the 600 coordinate on the Y-axis. So, in fact, the actual aspect ratio is 0.59, and thus the metrics are useless indeed…

But again: should we then _assume_ to be always dealing with badly produced fonts? Or could we just expect font metrics to tell the truth? For if we won’t, then we’re totally lost, and will make things even worse for professionally produced fonts, which do honor the specs.

(As for non-Latin scripts: it’s indeed up to the discretion of the font designer how to draw the height of, say, CJK characters or the size of the teeth in Arabic, but always _relative to the xHeight_ as stated in the font’s metadata, so the font behaves consistent with the specs.)

At Textus.io, we therefor rely on the font’s built-in metrics metadata, for now. But since we are obsessed with fool-proof typography, we are indeed considering to look at the actual coordinates of the outlines instead…

I do not expect browsers to do deal with inconsistent font metrics, though. As a developer, I instead want to rely on browsers behaving consistent, being assured they won’t ‘fix’ things I already fixed, for then the outcome will be totally unpredictable. That’s why we have standards and specs after all, haven’t we?

[Manishearth]

> But again: should we then _assume_ to be always dealing with badly produced fonts?

A major theme of the web platform is to assume the worst, because the worst is actually often not uncommon.

Another major theme is backwards compatibility. You've mentioned a fix that would break all previous sites relying on this behavior. Fixes that require a clean-slate redo of the web just won't work.

[irishsultan]

Note that these are mostly user configurable settings (although it's only the default font size that can be configured, not the other absolute and relative values)