Speak for yourself. Tailwind isn't universal.

I think the answer is that different people are sensitive to different things. I'll often come across articles going to great length to reduce some minor jank in animations or page load, and I'll be looking at it thinking yeah, I can see it, but it really doesn't bother me enough to fix. Certainly not by going to these lengths.

Meanwhile, FOUC bothers me a lot, to the point where I can't understand that its accepted in any form. I'd much rather that I don't get shown the page at all until the real font is loaded. Otherwise my eye will have tracked to the text, started reading and then there's a jarring reflow and I lose my place and have to find it again. If I'm scanning for information through lots of websites, it does mentally tire me.

Why do you think that's a majority view? Google's page speed metric which they use as a SEO signal is followed by many webdevs and it very strongly encourages displaying text with system fonts while custom fonts load, and that the top of the page is displayed quickly:

"Ensure text remains visible during webfont load ... Fonts are often large files with slow load times. Some browsers hide text until the font loads, causing a flash of invisible text (FOIT)."

https://developer.chrome.com/docs/lighthouse/performance/fon...

"First Contentful Paint (FCP) is an important, user-centric metric for measuring perceived load speed because it marks the first point in the page load timeline where the user can see anything on the screen—a fast FCP helps reassure the user that something is happening."

https://web.dev/articles/fcp

If you hide the page content from displaying until custom fonts load and your header image loads for example, you'll likely get a red/unacceptable score.

This adjusts properties such as x- and cap heights, which determine relative proportions of characters within the line. For example, in a browser supporting font-size-adjust, any font can be used as small caps.

But I must say I don't agree with `font-display: optional` advice. It indeed maximize the LCP and CLS metrics, but it does that to the extent that the results become detrimental to the user experience. Like, if I open that link in a private window, and then hit refresh, the layout shifts, because I don't have their custom font on the first load, but do have it on the second one. This doesn't make sense! Do you want me to see your custom font or not?

I would say that if you _really_ care about the page being ready as fast as possible, you should use `font-style: system-ui`. If you _really_ care about your fonts, you should use `font-display: auto` or `font-display: block` (and, yes, tweak fallback font metrics). If you care about _both_, tough luck, they are inherently in conflict and you need to pick one side. `font-display: optional` let's you formally pass the automated test with flying colors, but doesn't seem to result in actually useful behavior?

Your hot take reduces to that the web should never have become a product, which is equally defensible and in my view the formulation more likely productive of interestingly nuanced discussion. For example, we could critique the Gopher and Gemini crowds' sort of conceptually Sapir-Whorf-esque approach to at least notional redress, or ask what effect clientside inference might come to have.

You can ensure the size won’t change even in the future with a font that hasn’t even been designed yet.

That’s a nice benefit.

But this technique isn’t correcting for some kind of mistake the typographer theoretically made, it’s adjusting for the fact that CSS sizes by the bounding box instead of the em-height. The font itself is unchanged and renders exactly how it’s designed, this just lets us use it in a more intuitive way.

IMO sizing by bounding-box was the wrong move in the original CSS spec, but that’s how digital type renderers have worked going back to the eighties, so the whole thing was probably too entrenched in the first place. And I have no idea if font standards of the day even had em-heights encoded in a way that could be read in font metadata.

Anyway, this whole feature is news to me, can’t wait to try it. Between this and text-box-trim (life changing), I’ve never been happier with web design.

As a long time print and digital designer I’m very excited to have these new type tools that meet the needs of digital typesetting on the web!

Also I think a proper implementation would require reference to line count in the CSS markup, and CSS seems to have an awful time with properties that depend on character or line counts. We still don’t have working line-clamp!

ex.

  div {
    font-size: 24px;
  }
  div[line-count > 2] { // doesn’t exist, and must be difficult to implement
    font-size: fit-width; // … what about vertical text?
    min-font-size: 8px; // maintain legibility
    max-font-size: 28px; // why not
  }