Yeah, this can be an issue, but you can improve on that with font-display (optional or fallback). With the default of block there’s a 3s blocking timeout, but with fallback it’s more like 100ms which is a reasonable compromise. Also not loading 3 different webfonts in regular, bold, and italics helps (you can definitely overdo it), but ~140k is still reasonable even for slower connections (especially if you self-host it so you don’t have the extra overhead of DNS/TLS/HTTP).

But then it looks nice for the 0.1% that take the effort to do this (and can stomach fontconfig’s XML), and not for the vast majority of people reading your site.

CC: @Seirdy

you definitely don’t get that with the default fonts.

Most OSes and browsers set default sans-serif and monospace fonts that fit together, and users are free to change these if they like.

The article also explicitly addressed how to change colors (such as code backgrounds) properly. Nowhere in the article did I mention font sizes. Maybe I wasn’t clear enough.

The article itself practices what it preaches; it uses default fonts without the resizing issues you describe, at least on the graphical browser engines I tested (Blink, Webkit, Gecko, Links, Netsurf, Dillo, and Trident [Trident tested via webpagetest.org]).

That just seems like an implementation defect rather than a problem with the concept of webfonts. I always test with webfonts disabled to make sure the results are reasonable.

why not store the rendered product and serve it directly

Use PDF/LaTeX. These can have complex formatting, hyperlinks, and equations.

This is not web.

Use MathML, the standard for equations in HTML

Only Firefox renders MathML, and the page size gets huge very fast.

Use unicode characters, like tex-conceal.vim does. I don’t recommend using more than a tiny amount of this.

Not good enough when we want to write complex formulas with a lot of symbols.

How do you go about changing the font for a website…?

You have multiple options. The three I’m familiar with are changing the default “sans-serif” font in your browser preferences (easy), editing your widget toolkit (gtk, Qt, etc.) config file, or adjusting fontconfig’s “sans-serif” alias (more complex).

Do you think the average user will know how to do this?

No. I figured this response would come up, so I addressed it in the article. See the dedicated section

This is inconsistent, though: you are wanting it to be good for users to set global preferences in one paragraph, and bad in another. You can’t have it both ways – either users should set preferences (in which case those preferences will override page authors’ suggestions), or they shouldn’t (in which case they’ll get the page author’s suggestion).

And that’s without getting into the way you dismiss all font-family options other than serif, sans-serif, and monospace as “branding”. Authors do often have a variety of reasons for their font choices which have nothing whatsoever to do with “branding”, but you simply declare by fiat that no such reason could possibly exist.

Consider a site like this one, for example. The author of that site has strong and informed ideas about how text and type ought to be set for web display, and they include the idea that default fonts are a sort of desperate last resort to be brought out in certain specific situations, but otherwise avoided.

And let’s break down this comment:

Beyond basic layout and optionally supporting dark mode, authors should not dictate the presentation of their websites; that is the job of the user agent. Most websites are not important enough to look completely different from the rest of the user’s system.

First of all, authors do not and cannot “dictate” presentation, as I’ve already pointed out to you. They can merely offer a suggestion which will be applied as a default. And the core model of the web is a three-layered platform of content (HTML), style (CSS), and interactivity (DOM). This is not a new idea; it is how the web has been fundamentally designed for decades now. The notion that the web should be utterly unstyled save by user-agents was not a consensus view 20 years ago (I know, I was there), and isn’t today, nor should it be. Similarly, the idea that websites ought to look like “the rest of the user’s system” was a catastrophic failure, and most of the CSS features intended to make this easy were deliberately (like the “system colors” of CSS2) deprecated and removed from the standards many years ago. Not to mention, web pages which look like “the rest of the user’s system” can be actively dangerous to the user!

All in all, you mostly seem to have immense difficulty with the idea that others might have different preferences than you do and, under the guise of “user choice”, you are essentially demanding that everyone else just switch to having your preferences. This is the only reason I can come up with for your repeated description of suggested fonts/styling/etc. as an author trying to “dictate”, or your sneering at how alternative fonts or styling are merely “branding” or some sort of assertion of personal importance.

If you want your site to look a certain way, you can achieve that, and you have. If you want other sites to look that way, you can do that too. But to demand that others throw away their ideas of what their sites ought to look like, in service to you who already have the capability to override their styling suggestions, is the very arrogance you attribute to those other authors. My suggestion is you learn to move past it.

Finally:

With Gemini and gopher, authors only send content and semantic information while user agents choose how to style it.

This specific use case seems to have reinvented the feed reader. Gopher is dead and may rest in peace; there’s no need to continue iterating on it or building gopher-alikes for what you apparently want, since feed readers will do just fine and feeds can even exist in the absence of a publicly-hyperlinkable version of the articles contained within.

Another well known technical writer that does this is danluu. I think it has a nice transcendence element to it - being at a place where you simply don’t care about fonts in your content.

“readable” was not the word I should have used. I meant something more like “minimal” or “text-based”. Kind of like media="print".

sans-serif fonts are generally easier for people with dyslexia or dyspraxia, too.

Remember that the default typeface for Netscape Navigator was freaking Times New Roman.

Wait, isn’t that still the default for most browsers (or at least a libre-equivalent of Times)?

the default typeface for Netscape Navigator was freaking Times New Roman.

This is a flaw, IMO. TNR isn’t optimized for displays. Most serif aren’t as readable as sans-serif fonts on low-res displays; not everyone’s using a high-res 96dpi+ screen.

the styling of text has been incredibly important for centuries, and even today it’s a substantial and exciting mode of artistic expression.

Users are free to set whatever preferred typography they wish. The great thing about computers is they enable users to easily alter content to suit their own personal preferences instead of having to use a publisher’s standard formatting.

I want my site to have a design distinct from others’ because it’s fun to do that, as a designer.

I don’t think this is a good thing. I recognize that it’s fun to design your site to suit your personal tastes, but readers have their own preferences too. Having one window on my desktop that looks radically different from everything else is distracting. Textual websites should focus on content and should respect the user’s preferred styling.

As I stated multiple times in the article, not all websites are textual. The article only applies to text-oriented websites.

The web of 1992 isn’t what went mainstream

The web of 1992 didn’t die either. Non-mainstream websites still run just fine. Gopher didn’t go mainstream either, but my gopher client still works correctly.

CSS was a mistake

I don’t dispute that users don’t change the defaults. What I have a problem with is text looking very different across websites, which results in a11y problems. A common example is sites that put light gray text on a white background. It is possible to override stuff like that of course, but usually other things in the CSS conspire to make the result even worse.

That it was posted to lobste.rs, a site for techncal links and technical discussion

Care to elaborate? My understanding is that web standards for accessibility features don’t require scripting.

I wish that were the case. Here’s an example of some JS I use on my personal site.

I have a mobile navigation menu which appears when when the user presses a button). You need to change the menu button’s aria-expanded attribute to “true” when the menu contents are visible, and to “false” when they aren’t (ref).

PS: I’ve seen your responses to the comments. It’s rare that someone with opinionated views in tech is still respectful of other opinions. Thank you for your demeanor.

In my tests, oxipng -Z -o max --strip all (my preferred solution for lossless png compression) seems to beat advpng. I updated the article to reference pngquant, thanks! Diff

Updated. Thanks! Diff

If you website is only text all contained in a single HTML file, then you’re probably right. If it contains a few inline images and a CSS file, then HTTP/2 is likely to give some advantages.

This does not necessarily make a big difference. Multiple connections are still possible, there is HTTP Keep Alive, and you might exhaust requests sequentially. It really depends on the specifics though. There were quite some people benchmarking this a few years ago and HTTP/2 did sometimes worse, sometimes better than HTTP/1.1 in real life setups. Pipelining exists in HTTP/1.1. So when not looking at benchmarks where one uses extreme cases of blocking loads things might look different.

TIL. Do you have any more info on this? I’d be interested to know more about the impact of said “‘requests’ to cancel.”

This is due to HTTP/2 Push which especially when you have a static file server (or something else utilizing this) potentially initializes pushes of file that the client already has cached.

Section 8.2.2 of the HTTP/2 RFC describes how the PUSH_PROMISE frame is followed by delivering data, which the client can cancel with the CANCEL or REFUSED_STREAM frame.

On another note this might also be interesting https://tools.ietf.org/html/rfc7540#section-10.4

There’s also an article giving an overview

Also for the story’s page I tried a website for a quick comparison and looks like with HTTP/2 everything put together takes 67ms longer.

Don’t get this wrong however. As mentioned it really depends on the specifics and for many websites out there it’s an improvement. It’s just a wrong assumption that HTTP/2 is always a benefit.

I can’t find it right now, but I also read an article about the implications of latency having an effect on which protocol behaves better (more in-depth than just general low vs high).