> "And the best part of an approach like this: browsers could just ship better defaults for common fonts. There aren't that many fonts in use, and at <=64bit of information needed per font, browsers could easily ship fallback configuration for the ~1000 most common web font names."
If we think this thought further we could separate the font metrics from the actual font shapes. The metrics are all that is needed for layout and the metrics data is tiny. We could load the metrics quickly then do layout and shape data loading in parallel.
This idea isn't new. TeX works that way. In fact the tiny font metrics data is all that TeX ever cares about and this data is enough for TeX to do its job, which is laying out the page. The actual font shapes are only read by other programs that turn the output of TeX plus the shapes into something printable or viewable.
You could use TeX to typeset documents with fonts you didn't own because the metrics are not protected and publishers used to distribute the metrics to authors freely. I remember that Springer did this with their Springer customized Myriad an Minion tfm files.
The idea is not even TeX specific, as far as I know Adobe used to ship their fonts with separate metrics files too. *.afm - Adobe Font Metrics were a thing.
Wouldn't it be nice to come full circle and separate the layout from the rendering again?
I had not known about 'font-display: optional' before. Now I wish more sites used it because there has been so many times where I started reading something on my phone with slow internet when it had not fully loaded yet. It’s really annoying to see the page jump around a while later after font loading finished and you realize that you just wasted data on nothing.
In my opinion, 95 % of websites should just use system fonts. They’re good enough for almost every need really.
Although I do wish there are a few standard font that is shipped across all browser. Sometimes I want the website to appear exactly the same on all System.
See my comment to the parent for an example of a site that needs to look the same (or rather - a portion of site - an HTML Canvas) that has to look the same on every device and which needs a specific font loaded to work properly. For my case, having a font that was guaranteed the same in every browser would have been very nice, and I would have gladly used that if it worked and fit the theme closely enough.
Even if there was consistency in the actual fonts their rendering depends on the platform/engine or even just the device settings. If you want precise display metrics you should use an image (SVG counts). If I've got large text enabled on my phone we could have the same exact device and my display metrics won't match yours.
Nice, but it's more important for my browser not to leak information about me via what fonts I needed to download.
Also, it gets really annoying when sites demand that my desktop look like my mobile phone but blown up really big. Twitter's already that way, and the Facebook redesign did the same thing.
There are a few metric compatible fonts used by stuff like pdf. and so on. I believe an alias for these fonts are needed. Obviously add an emoji and UI font. that will be the best
And with smartphones, they're no longer installed on every system. I really wish that Chrome and probably other browsers would install a set of fonts from Google Fonts. I don't see a reason why this shouldn't be possible. That's what most sites use, anyway. I guess it's related to Google being able to track usage of these fonts.
Is it possible to configure your browser to treat every site as if it used 'font-display: optional'? I'd love to be able to do that. Seems like it should be up to the user to decide, not the web developer.
Browsers typically let you define a user stylesheet somewhere in the settings. I tried it in Safari with a simple `body {@font-face {font-display: optional;}}` but I could't verify if it has any effects. I think it is difficult because @font-face will be evaluated differently than usual css, say `color: red`. Maybe someone who has a better understanding of css could try it...
It gives you a pretty good looking native system font for most platforms.
Yes, it means you don't get as much control over your "brand" as a custom font. But it's a great option for those who value users' experience (fastest possible content load time, no font loading reflow, etc) over maintaining some nebulous notion of a consistent brand image through fonts on content/UI. The former tangibly benefits users, while the latter only (marginally) benefits the company/brand (99.9% of your users couldn't care less what font you used as long as it's not horribly out of place or ugly).
I would go as far as to say say this is the right tradeoff for most product/brands where your primary product/service isn't text-based (books, articles, other publications).
And if your layout is brittle enough to need pixel-perfect control over font dimensions, that's something better addressed through a more dynamic layout since it will also become a maintenance nightmare, as that's basically the antithesis to a responsive layout.
The “font-display: optional” looks quite interesting, and I’ll keep that in mind for projects, but I don’t think most websites would care for it. If they really did, they’d first chop off massive JavaScript and images first.
Compressed font formats aren’t typically as heavy as these kinds of resources. One could also optimize the font file size by choosing only the characters used by the website and getting rid of the rest.
> The fallback-to-custom-font matching works really well in most cases.
The article goes on to note that this is an approximation and that it doesn’t work well for all cases. I looked at the comparison screenshots, and while the text size and wrapping may be close enough, it’s quite different in terms of readability.
Websites may choose certain fonts for better readability and to better show the content structure and hierarchy. Whatever the reason, there is a specific set of preferences that the website author chose (especially if they decided to use custom fonts). That gets lost with generated substitutions like this.
It may be a good idea to spend a little time to decide, by hand, which fallbacks are good enough (which most websites do by including system defaults in the list, even a generic sans serif or serif). That way, the website’s look is still under your control in a better way (as the designer and/or developer).
The problem with fallback corrections is that you don’t know certainly what the fallback will be, and still further, it will not be the same across all platforms, which is an absolute killer of the concept.
Further, I suggest that in most cases you even shouldn’t know what the fallback will be—that most of the time I really, really wish people would fall straight back to a generic family. I’m tired of `font-family: Some Fancy Sans, Helvetica Neueueue, Helvetica, Liberation Sans, Arial, Droid Sans, sans-serif` and the likes. Mostly you should just go with `font-family: Some Fancy Sans, sans-serif`, and revel in not knowing what the fallback font actually is, because you’re following the user’s preference (well, for the small fraction of users that have expressed a preference, anyway; but we’ll probably appreciate it).
I might. One of the target groups for one of my web sites is people who are browsing on a low-end phone in basements and underground parking garages with poor cellular connectivity. (It's very geographically specific, but the users still number in the tens of thousands.)
"this value also allows the browser to determine whether the custom font is even used at all, using the user’s connection speed as a determining factor where slower connections are less likely to receive the custom font."
I recently had to deal with this issue, except in my case, font-display optional really couldn't provide a decent solution.
My use case was, I was building a website that uses HTML canvases + text and emojis to let users build custom greeting cards. I wanted users to be able to share their cards with their friends (or save it for later), but I didn't want to deal with signup or saving stuff to a database - so I just let people generate a long link that contains the card content. Since we were only using emojis and text, and since I was ok with just using one type of font, I figured I could shrink that info into a link - even if it's ugly[1]
When I first stared, I just used "Impact" font (I wanted a meme vibe), and it worked great - until I loaded it on my phone. So then I found a similar-ish font on google fonts, and that's when I first started seeing race issues. I spent some time messing with it, added preload, but it still doesn't load consistently. Especially I've noticed that the images that are used for the inside pages of a card (which are pngs generated by setting up a canvas then saving it as a blob) seem to load with a default font in race conditions. It all works again if people click to that image and load the actual canvas, but I doubt some people will do that. So it's very frustrating and I really wish there was a better way - because there really are cases where a specific font is necessary.
I think it's probably still not fixed, but here's an example of the type of load that was causing me problems.
I haven't examined your site's code, but it sounds like you should be using the CSS Font Loading API (https://drafts.csswg.org/css-font-loading/) to ensure the font(s) you want are loaded and ready, before attempting to draw text in canvas.
Thank you for the tip. I think I did briefly look at that, but the "experimental" banner on the web api documentation page scared me off. Looking at the browser compatibility chart, it does seem to be pretty widely implemented at least.
If we think this thought further we could separate the font metrics from the actual font shapes. The metrics are all that is needed for layout and the metrics data is tiny. We could load the metrics quickly then do layout and shape data loading in parallel.
This idea isn't new. TeX works that way. In fact the tiny font metrics data is all that TeX ever cares about and this data is enough for TeX to do its job, which is laying out the page. The actual font shapes are only read by other programs that turn the output of TeX plus the shapes into something printable or viewable. You could use TeX to typeset documents with fonts you didn't own because the metrics are not protected and publishers used to distribute the metrics to authors freely. I remember that Springer did this with their Springer customized Myriad an Minion tfm files.
The idea is not even TeX specific, as far as I know Adobe used to ship their fonts with separate metrics files too. *.afm - Adobe Font Metrics were a thing.
Wouldn't it be nice to come full circle and separate the layout from the rendering again?