[HN Gopher] Font loading on the web
___________________________________________________________________
Font loading on the web
Author : payne
Score : 41 points
Date : 2021-01-31 07:17 UTC (1 days ago)
(HTM) web link (www.industrialempathy.com)
(TXT) w3m dump (www.industrialempathy.com)
| newscracker wrote:
| 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).
| willemlabu wrote:
| Just a note that the solution proposed here will not work with
| JavaScript disabled.
| weinzierl wrote:
| > _" 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?
| Gorgor wrote:
| 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.
| wtetzner wrote:
| 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.
| ksec wrote:
| > 95 % of websites should just use system fonts.
|
| 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.
| SilasX wrote:
| 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.
| postalrat wrote:
| Are you a designer?
|
| If you want your document to look the same on all systems
| create an image.
| kgin wrote:
| That's definitely the correct move given how browsers work,
| but I don't think it's wrong to wish for font consistency.
| giantrobot wrote:
| 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.
| jfk13 wrote:
| The site should appear exactly the same in a fullscreen
| browser on a 27" desktop monitor, and on an original iPhone?
| That's rarely a useful goal.
|
| For a page that _really_ needs to look "exactly the same"
| everywhere it's viewed, maybe PDF is a better choice than
| HTML+CSS.
| sudosteph wrote:
| 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.
| robertoandred wrote:
| There are a few standard fonts, but no one wants to use them.
| mrob wrote:
| uBlock Origin lets you block/allow web fonts globally or per
| site.
| ArtDev wrote:
| Interesting, but I don't think I will be using `font-display:
| optional`anytime soon.
| recursive wrote:
| I might use while browsing sites you design. Browsers are
| (theoretically at least) agents of the user.
| reaperducer wrote:
| 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."
|
| https://css-tricks.com/almanac/properties/f/font-display/
| wtetzner wrote:
| Any particular reason why? Because without additional context,
| it sounds like you value pushing your preferred font over the
| user's time.
| chrismorgan wrote:
| 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).
| eins1234 wrote:
| One alternative is to simply use the system font stack
| popularized by Bootstrap's Reboot reset:
| https://getbootstrap.com/docs/4.0/content/reboot/#native-fon...
|
| 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.
| sudosteph wrote:
| 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.
|
| [1]
| https://emojify.cards/?canvas-0=HEY+357+576+6.417+9.018+0+0+...
| jfk13 wrote:
| 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.
| sudosteph wrote:
| 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.
___________________________________________________________________
(page generated 2021-02-01 23:02 UTC)