I don't think this is an epidemic or anything, but I've seen it done a few times and even advocated for. This is what I mean...
“Typography on the web is in single color: characters are either black or red, never black and red …Then emoji hit the scene, became part of Unicode, and therefore could be expressed by characters — or “glyphs” in font terminology. The smiley, levitating businessman and the infamous pile of poo became true siblings to letters, numbers and punctuation marks.”
Using emojis in code is easy. Head over to emojipedia and copy and paste one in.
Roel Nieskens released a tool that lets you upload a font file and see what’s inside, from how many characters it contains to the number of languages it supports. Here’s what you see once you upload a font, in this case Covik Sans Mono Black:
Why is this data useful? Well, I used this tool just the other day when I found a font file in a random Dropbox folder. What OpenType features does this font have? Are there any extra glyphs besides the Roman alphabet inside? Wakamai Fondue answered those questions for me in a jiffy.
There’s a lot of good news in the world of web fonts!
unicode-range, the last modern browser to do so.font-display are landing in Safari and Firefox.Using custom fonts in a performant way is becoming far easier. Let’s take a peek at some things we can do when using custom fonts to make sure we’re being as performant as we can be.
Using custom fonts is getting increasingly easier. We’ll cover the basics of usage here and get into the more in-depth features that are helpful for developers who want to level up and aim to perfect advanced concepts, like loading font files.
System font stacks got hot about a year ago, no doubt influenced by Mark Otto's work putting them live on GitHub.
The why, to me, feels like (1) yay performance and (2) the site looks like the rest of the operating system. But to Mark:
Helvetica was created in 1957 when the personal computer was a pipe dream. Arial was created in 1982 and is available on 95% of computers across the web. Millions, if not billions, of web pages currently use this severely dated font stack to serve much younger content to much younger browsers and devices.
As display quality improves, so too must our use of those displays. System fonts like Apple’s San Francisco and Microsoft’s Segoe aim to do just that, taking advantage of retina screens, dynamic kerning, additional font-weights, and improved readability. If operating systems can take advantage of these changes, so too can our CSS.
There is a great bit in here where Glen uses Font Style Matcher to create some CSS for a fallback font that has font-size, line-height, font-weight, letter-spacing, and word-spacing adjusted so perfectly that when the web font does load, the page hardly shifts at all. Like barely noticeable FOUT. Maybe we'll call it FOCST (Flash of Carefully Styled Text).
The font-display property defines how font files are loaded and displayed by the browser. It is applied to the @font-face rule which defines custom fonts in a stylesheet.
@font-face {
font-family: 'MyWebFont'; /* Define the custom font name */
src: url('myfont.woff2') format('woff2'),
url('myfont.woff') format('woff'); /* Define where the font can be downlaoded */
font-display: fallback; /* Define how the browser behaves during download */
}Time for another pairing screencast! This time I have Zach Leatherman on, from Filament Group. Zach has done a lot of research, writing, and speaking about web font loading the past few years. He's got a comprehensive guide on it!
There are some problems with the default way that custom fonts are loaded. As in, just linking up a font in some CSS through @font-face. Even the way Google Fonts provides you to use their fonts Zach calls an anti-pattern (ultimately it's just vanilla @font-face). Different browsers do different things with @font-face. For example, some versions of Safari make type set in a custom font invisible until the font loads, but has no timeout, so if the font fails for any reason, you could be in the ultimate worst-case scenario: forever-invisible text on the site.
You don't have a heck of a lot of control over how @font-face fonts load, unless you take matters into your own hands. That means things like: inlining the font, subsetting the font (either with a "critical" set of glyphs, or at least reducing glyphs to the language in use), using font loaders to determine when the fonts load and altering classes to use them. That last one is particularly interesting. When exerting control over font loading, you not only have to deal with when/how the browser loads the CSS that contains the @font-face, but also when/how the browser comes across text elements that are told to use those fonts. Fonts that aren't used aren't downloaded. So sometimes the procedure is to force them to download, wait for them to download, then apply classes to actually use them.
Some tools we looked at:
Updated on January 12, 2017: Proper support checks are now part of the article body. Added information about the block value. Minor tweaks and copy edits. Enjoy!
If you're a regular reader here at CSS-Tricks, chances are good you know a bit about web fonts. You may even know a few useful tricks to control how fonts load, but have you used the CSS font-display property?
The font-display property in CSS is available in Chrome, and emerging in Firefox and Safari (but you might want to check browser support for yourself, since things change all the time). It's a simpler way of achieving what the Font Loading API is capable of, as well as third party scripts such as Bram Stein's Font Face Observer.