I once had to suffer through a tethered 2G internet for a few months, and made an extension to disable web fonts[0] because they felt like a waste of bandwidth. Ever since, I've appreciated the "system-fonts" design ethos and tried to stick to that everywhere - most content on the internet doesn't need to choose it's own set of typefaces (almost inevitably from Google Fonts).
These days, I keep web fonts disabled using uBlock Origin, and enable them on a need-basis when sites decide to use web fonts as icons. My favorite glitch is Banggood which somehow fallbacks to show me icons for PHP, Java, and Firefox in the navbar [1] because the glyph matches the file-icons system font somehow.
Firefox has a setting "allow pages to choose their own fonts, instead of your selections above" (browser.display.use_document_fonts). I like how this wording considers user-defined fonts the default.
I had this problem when putting Into Sans as my font until I realized that I needed to install a separate package on my distro for the emoji set for that font. I'm guessing that this setting just doesn't allow fallback to another font if the one that you selected doesn't have emojis in it, which sort of makes sense but realistically is bad UX; there should be a way to say "use my preferred font whenever possible" without saying "just give up if my preferred font doesn't support a given character". I guess the implementation might be tricky due to the fact that whether a given substring even renders as a single character or not (I might be using the word "character" incorrectly here; I know there's a lot of vernacular here).
I understand the author’s stance, but it’s probably mostly motivated by the fact that he runs a web publishing service (mataora.blog) where you can potentially write in any script, making it hard to support good multi-script typography without loading webfonts conditionally[0] (also, except for the Noto family, there are almost no universal, good-looking options.)
Thanks to variable fonts, you can nowadays get a full typographic palette (including small-caps, italics, all weights from 100 to 900) on a 300KB budget, sometimes less. The article sports an image that’s 170KB, so it’s a question of priorities I guess.
You can also subset a couple of weights and come in under 60kB, which is what most sites should be doing. (Obviously not applicable for multilingual sites and esp East Asian ones)
Edit: also, fonts are by default loaded conditionally by browsers.
That’s one of the reasons you typically use a preload to speed things up: otherwise the browser will wait for the first paint following CSSOM construction to know which font faces are used on the page, and thus what to download.
In other words, specifying the 200 @font-face’s possible on a site actually poses no issues - only those fonts actually used will be downloaded.
Not sure why anyone would want to specify a font for content like a blog. To think your taste is more important than peoples preferences and settings seems incredibly self centered, or dare I say narcissistic.
There are no “peoples preferences” when it comes to fonts. 99% use the default settings of their browser, so any effort made to improve typesetting of a particular publication is I think more than welcome.
This! I use a custom font for my blog because there are meaningful layout and design differences between typefaces. Even "similar" faces like Arial, San Francisco or Roboto look dramatically different applied to a whole page—font metrics affect the leading (line-height), paragraph width, font size and more. If I don't know the font, those are all unknown variables, and I don't want to QA my blog on 1000 different browser/OS/device combinations.
So I use two weights (regular and bold), each weighing in at 30kb, woff2 only, preloaded in the HTML and served with long-life cache headers. I know that some users have turned off web fonts, but they've chosen that pain. For the other 99%, I just want my blog to look decent.
> A webfont can be efficiently small if it includes characters only for the latin script. But what if I want to write Greek? Or Korean? Or Tamil? Something semi-terrible happens then. Thankfully, (probably) the text will still be displayed because the browser will fall back to another font for the characters the webfont of choice does not define. This will probably be a system font, which means it will probably define lots and lots of characters for all scripts. But, terribleness will strike when the style of the fallback font is completely different from the style of the primary font.
While I'm in the camp of `font-family: serif/sans-serif`, this paragraph strikes me as strange. If you choose a font for your own content on your own website, why would you choose something that doesn't contain all the characters you need?
The fallback problem is most commonly seen on websites that host user contents where the user can upload some character that the website maker hasn't prepared to host.
On a personal site that needs non-Latin characters, you either have to host a big font, or you relinquish control completely by setting `serif` and `sans-serif`. There really isn't much terribleness can happen, unless you mis-configure the language of your page.
I'm in favor of the latter, because when I browse the web as a user, I've seen how many web pages are broken when CJK characters are mixed with Latin alphabet. The only sane way for me is to block all custom fonts on the web. I've configured my OS to display both English and Chinese in a relatively harmonic manner (not a trivial effort on Linux, to be honest), and there's a much better chance that this system works better than whatever the website wants to do.
>While I'm in the camp of `font-family: serif/sans-serif`, this paragraph strikes me as strange. If you choose a font for your own content on your own website, why would you choose something that doesn't contain all the characters you need?
Once the site is choosing their own font you are probably relying on non-domain experts to do the choosing of the font, probably a developer or designer. These people sometimes will think it works on my system on the language I have tested it on and not think off hand but does it work with all the characters that need to be supported. Thus when your site chooses not widely available fonts or builds their own fonts this is a potential source of bugs.
For a personal blog, the number of languages is likely to be no more than two or three at most (putting aside any comments or other world-writable parts of the page). So it seems that one could easily trim the font files to only the needed characters, or even load them only for specific articles that need them.
The bigger issue would be a general forum where people can and do write in any known language. And not only would the site have to support the character sets, the admins would likely have no way of even knowing if the various characters were being displayed correctly let alone if the font had a good readability/seriousness in that script.
>"The problem starts with humans having languages with uncountably many different characters. A webfont can be efficiently small if it includes characters only for the latin script. But what if I want to write Greek? Or Korean? Or Tamil? Something semi-terrible happens then. Thankfully, (probably) the text will still be displayed because the browser will fall back to another font for the characters the webfont of choice does not define."
Hmmmm, what about downloading webfont package language character sets piecemeal? Load the Greek alphabet if the page needs a greek character, etc. Granted logograms will be pretty heavy, but maybe with some statistical analysis they could be subsectioned into "frequently used together" categories.
This is well-argued, but I have two rebuttals, I suppose.
> A webfont can be efficiently small if it includes characters only for the latin script. But what if I want to write Greek? Or Korean? Or Tamil? Something semi-terrible happens then.
Okay, but you know the characters you need for your website. My web site is probably never going to have anything but Latin characters (I'll get back to that "probably" in a moment). This article doesn't, either. "But what if your web site displays user-generated content, smart coyote," you say. Well, then, don't use a webfont. Or, possibly, consider that probably, which leads me to
> But, terribleness will strike when the style of the fallback font is completely different from the style of the primary font. You can see an example of said terribleness here.[1]
While that example is indeed terrible, it's also deliberately terrible, which is a rather important point the article elides! The example loads Source Code Pro as the main font but subsets only a few letters from it, then sets the fallback font to be Impact. This is being done as a deliberate contrast to the example right above it, which sets a much more reasonable fallback font stack.
And, now we're at that "probably": as the web designer/developer, you're the one setting the fallback stack for your fonts! If "terribleness strikes" because "the style of the fallback font is completely different from the style of the primary font," well, don't set Impact to be the fallback font for Source Code Pro.
I would argue the author absolutely can show everyone the beauty of Century Supra or EB Garamond if they so choose to, because they're writing in the Latin-1 subset of characters. You can't show off the full range of EB Garamond's character set without increasing the initial download size, but you could use a subset of it combined with fallback fonts which include other characters and don't have completely different styles.
(Of course, you could also specify "font-display: fallback" or "font-display: optional" and just send the full font along with your well-chosen fallback font stack.)
I like letting the user pick a webpage's font. But I've noticed that most users don't customize their default fonts, resulting in sans-serif mapping to Arial (unstylish), and monospace mapping to Courier New on Firefox (painfully thin to read). And on Android you can't install fonts to your browser, though it's less of a problem because the default Roboto font is actually decent.
> most users don't customize their default fonts, resulting in sans-serif mapping to Arial (unstylish), and monospace mapping to Courier New on Firefox (painfully thin to read)
I lean towards defining a font stack for this reason.
It would be nice if there were a way to specify user-defined font vs. default font in CSS so something like
I happen to really hate SVG. I've been feeling like it's a standard that should have gone away 20 years ago.
So in many cases where I'm building a website for a brand where they have lots of icons that need to scale, I create a font with the outlines of all their icons.
This is great for lots of reasons. The employees at the company can use the font when they need to drop in a corporate icon into a blog post. I can then maintain a repository for the font and the company can use those vector icons anytime in simple documents.
She points out a few failure cases with icon fonts, like 1) uninterpretable by screen readers for the blind, and 2) don't work well for dyslexic people who have configured their browser to use specialized fonts that are easier to read.
The great part is that unlike SVGs you don't need to include specific image files for each one, or worry about updating those files across lots of systems. Just update the font. Client wants to use their icons in their printed pieces? Just give them that font rather than a whole bunch of files. Include the font with articles for print, and the printer can outline all the graphics.
Tl;dr, fonts are just a fantastic way to bundle lots of vector files on a per-client basis. Plus most clients feel super special and cool that they have their own font!
And the tech we use is old. Old. We maintain these in FontForge, which is a Mac X11 app.
>I happen to really hate SVG. I've been feeling like it's a standard that should have gone away 20 years ago.
What vector format should have replaced it? I personally think the W3C should just have accepted VML, not because I think it is better but because it was already widely supported (IE, and with a little work Netscape on Windows) so at the time it would have taken less work to get Vector graphics (for Netscape to add support on other platforms). But then I am more a bazaar type of person than a cathedral type.
I'm not sure if the downvotes are because I like making fonts out of icon sets, (really: useful practice!) or because I went against SVG.
Look, SVG is fine for moving shape files around if something won't handle EPS. But it's an all-purpose vector definition that is by design not optimized to any purpose. It's shitty for replacing fonts, backgrounds, or animations that could be done in more compact domain specific formats. As someone who came up doing animation in Flash, just... don't even bring up SVG. I'm a lot happier to animate all my beziers and points in code in something like PixiJS than lean into a bloated format designed for... what is SVG for? Uploading t-shirts to cafepress or something?
don't know about the downvotes, maybe it's the use of the slang. I guess I like SVG fine enough, but probably that is because I am unfamiliar with working intensively with other formats.
on edit: when saying maybe it's the use of the slang it's just to indicate my general feeling that HN downvotes are an insoluble mystery, even someone as wonderful as I gets downvoted at times, and is that fair? The answer is no, it sure isn't.
Hah. Well I know, you're never supposed to ask on this board. Sometimes I just get taken by surprise though... like, there are really people with strongly positive views about SVG out there? Now I'm curious who they are and why they like it.
No, generally we just have a few dozen at most per font, so we put them in the latin alphabet where they'll be relatively easy to find, and then keep a corresponding SCSS file where each is mapped to a single character of content by a descriptive name, similar to how FontAwesome does it.
That's a reasonable question. I don't know. As a ::before content some readers might issue a verbal hiccup, but they're generally never used in inline text; they're isolated in a div tag of their own as graphical elements, the way an SVG graphic would be. I'm struggling to think of a case where they'd ever need to be read out loud, but if there was you could add aria tags. It's usually used inside a header or float that isn't meant to be printed or read aloud.
These days, I keep web fonts disabled using uBlock Origin, and enable them on a need-basis when sites decide to use web fonts as icons. My favorite glitch is Banggood which somehow fallbacks to show me icons for PHP, Java, and Firefox in the navbar [1] because the glyph matches the file-icons system font somehow.
[0]: github.com/captn3m0/disable-web-fonts
[1]: https://imgur.com/a/k0HG1i5