Comment by _fat_santa | Hacker News Reader

Comment by _fat_santa | Hacker News Reader

Parent Full thread

> If you embed a font hosted somewhere else you expose some of your user data to them. Now with fonts there's a really simple solution: Just don't. As an added bonus, hosting fonts on your own server is faster as it goes through the same HTTP connection.

I never quite understood the debate around fonts. You could use the CSS/Link import that Google provides, but that's never the optimal solution. Like you I always download the fonts and use them directly via @font-face.

The only advantage I see to using Google Fonts / some privacy respecting font service like this one, is when you are first prototyping an app and want to either test fonts, or want to move quickly and not worry about setting up fonts properly. We also used in a places like Storybook where having correctly set fonts is not as important.

But even if you did use it in prototyping, it's best practice to pull down those fonts and store them locally before going to production (at least in my mind).

Am I missing something?

On Firefox desktop, I force literally all fonts -- serif, sans, what-have-you -- to Linux Libertine. Dingbats can look odd, but you get used to that.

For reasons I am sure I will never fathom, browsers on mobile provide all the same settings options, and religiously ignore them.

I used to do this, but it broke a lot of websites, especially those that use custom fonts to display symbols.

Nowadays, what I do (and recommend to others) is to set Firefox to never send a referer cross-origin, so google fonts and similar don't get to see what website I'm on. I've found that very few websites break with this.

Font icons is another one of these things that some web developers tend to do and should probably stop. SVG icons are superior in every way—at least all the ways I can think of.

A growing number of websites support dark mode theming, but not all of them. When I open a page in reader mode and switch to dark theme, I don't expect logos in the text to fade into the background. Svg is also often much larger than a font file, especially one that's subset.

While it's not svg or on the open web, I have a particular hate for sborn.jpeg in ebooks, as I read my ebooks in dark mode at night and having occasional section break symbols (ornaments) white on black is particularly irritating. Other unnecessary images often found in ebooks include bullets, chapter titles flourishes, letters with accents, and even the chapter title itself.

> I don't expect logos in the text to fade into the background.

You can use @media (prefers-color-scheme: dark) { ... } in the style inside the .svg and browsers render it accordingly in dark/light mode. But yes, not being able to set the color from the page CSS is annoying.

I was manly talking about icons, but not logos. Icons usually only have one color—which is often the same color as the surrounding font color. If your icon is only a single <path> (most good icons are) then you can color them with:

    svg { fill: currentColor; }
    .parent { color: var(--text-color); }

When you use dark-mode the color of the svg path should change with the text as long as the author changes --text-color in a dark-mode media query.

    @media (prefers-color-scheme: dark) {
        --text-color: wheat;
    }

I don’t know about the size, but I suspect that if any the difference is negligible. Most of my icons are a few hundred bytes uncompressed. And I usually put them in a sprite which is usually well under 50 KiB uncompressed. I don’t know how large font icon files are, but I suspect they are not that much smaller that it makes a difference.

> Svg is also often much larger than a font file, especially one that's subset.

Subsetting is where SVG shines, though.

For icon fonts, you can much more easily subset SVG icons than a font file. Font file subsetting needs dedicated tools like font editors (with Icomoon being a common choice these days) and often manual maintenance/upkeep, whereas SVG tree shaking is a natural part of any web bundler (webpack, etc) and automatically adapts to your icon usage and tools in your web bundler such as bundle splitting/lazy loading.

The Fort Awesome JS libraries behind Font Awesome's SVG icon fonts reduce things further from SVG XML files to tree-shakeable ESM files [EcmaScript Modules] that include just a few pieces of metadata and the lone important path text (sticking to a single SVG path per icon), then build the SVG DOM at runtime (as VDOM in the case of the React library), including making sure it follows fill: currentColor to pick up the text color. Minified and tree-shaken by most web bundlers the ESM files are very competitive with any other font format and the convenience wins of automatic subsetting by web bundler are hard to match.

I use Calibre for font subsetting, usually for use in ebooks, but I've used it for a website as well. The only gotcha I've found is that Calibre doesn't recognize css content attributes (`div.icon{content:"source:"}`), and that font names need to be correct. This is pretty trivial to get around, and generally only needs to be done once.

I've never used webpack or any other bundler on any personal website I've written, nor have I ever used react or other heavy frameworks (I used jQuery when I was in school). Perhaps these are useful on larger websites, but I prefer to avoid scripts in general, with the sole exception being scripts that parse a data source to generate a page client-side (most pages on my system are static, so I don't even have php or such installed). To me, automation means I make changes to the html on my server and reload the page.

SVGs are still often better subsetted raw ("unbundled") in that case both for local development and on HTTP/2+ servers. Things are slowly moving back away from bundlers/bundles which were mostly about getting the most out of HTTP/1.x tradeoffs most of which either no longer apply (because changes in browser caching rules for privacy reasons) or are mostly obsolete concerns (with HTTP/2+).

You aren't going to get easier subsetting in a modern browser than a folder full of SVGs and the browser only pulling the URLs it needs as it needs them rather than an entire bloated icon font format all at once up front. No need to double check that Calibre has got the right font subset from your CSS or to open Calibre at all, just upload the folder of SVGs and let the browser "subset" it, in the classic ways of HTML going back to its origins. Even less "automation" than Calibre.

Not advocating for font icons but one advantage is that their color can be styled form the page CSS - for SVG that only works if the SVG is embedded in the HTML, not if it is loaded externally or from data URLs.

You can use SVG sprites to overcome that limitation. My SVG icons are usually only:

    <svg><use href="/path/to/sprite.svg#my-icon" /></svg>

Good SVG icons are a single <path> which can be colored in your CSS with

    svg { fill: currentColor; }

Then it will take which ever font color it inherits.

Off course I usually wrap this in a component and only write <app-icon icon="my-icon"></app-icon>.

If the font is already in your browser cache (which it might be if they're hosting it on a common CDN) web pages should load with the correct font right away instead of either loading blank areas or a default fallback font before switching to the correct font, causing jank.

The best solution here is to use standard fonts that are available in all browsers, of course.

Sorry, not since cache partitioning. https://developer.chrome.com/blog/http-cache-partitioning/

Privacy killed the shared cache.

And it's such a niche privacy issue too. I would gladly take a shared cache over cache isolation. Especially for something used on as many sites as Google Fonts is.

You may be interested in the LocalCDN extension [1] which tries to solve the privacy vs speed issue for common resources by intercepting known remote resource requests and returning a local copy.

1: https://www.localcdn.org/

It looks like it's only "officially" supported on Firefox, but I'll give it a try. Thanks.

For data protection reasons, this has not been the case for a long time. Both for Firefox and Chrome.

Reply on news.ycombinator.com