I think I had the same wooahhhhh coool reaction as so many others did when this tweet was going around:
If you were developing sites in 2006, then you may have worked with a designer like me who was all up in your business about fonts not looking exactly the same in the browser as they did in mockups.
Then you may have tried explaining to me the pains of cross-browser compatibility and how different browsers render fonts differently from one another. In response, I likely would have sent you an image file that contains the content instead to make sure everything looked the same in all browsers. Yes, I was one of those designers.
Web fonts have come a very long way since then and we now have tools to tweak the way fonts render in browsers. Some have been around for quite a while. I remember my mind nearly bursting with excitement when I discovered FitText.js and Lettering.js way back when.
There are still plenty of situations today where adjusting fonts is needed to ensure the best legibility despite having all these fancy tools. We're going to cover a few of those in this post along with methods for how to deal with them.
There was a time when the smart move in picking fonts for a website was to a font-family that was supported across as many platforms as possible. font-family: Tahoma; and whatnot. Or even better, a font stack that would fall back to as-similar-as possible stuff, like font-family: Tahoma, Verdana, Segoe, sans-serif;.
These days, an astonishing number of sites are using custom fonts. 60%!
No surprise, there is also a decent amount of pushback on custom fonts. They need to be downloaded, thus there are performance/bandwidth hits. There is loads of nuance on how you load them.
Also no surprise, there is some advocacy for the return to local fonts. Fast! Good enough! Let's look at that for a sec, then also look at using them within SVG.
Over on the Typekit Blog, Tim Brown has written about an exciting development in the world of web fonts: an improvement to the OpenType font file specification.
This might not sound all that exciting at first, but “variable fonts” allows designers and developers to embed a single font file into a webpage and then interpolate the various widths and weights we need from a single file. That means smaller files, fewer requests, and more flexibility for designers. However, this format isn’t available to use in browsers yet. Instead, it shows that there’s a dedicated effort from Google, Microsoft, Apple and Adobe moving forward:
Imagine condensing or extending glyph widths ever so slightly, to accommodate narrow and wide viewports. Imagine raising your favorite font’s x-height just a touch at small sizes. Imagine sharpening or rounding your brand typeface in ways its type designer intended, for the purposes of art direction. Imagine shortening descenders imperceptibly so that headings can be set nice and tight without letters crashing into one another. Imagine this all happening live on the web, as a natural part of responsive design.
If you’re interested in learning more, we wrote about the call for a responsive font format which explains why it’s going to be so darn helpful in the future. John Hudson also wrote a long overview of the whole story, and the spec is here.
Florens Verschelde digs into the numbers behind the concept Tim Brown was talking about the other day.
When I tried wrapping my head around Tim’s implementation, and creating variants of it, I had a hard time figuring out what was going on exactly. I did a lot of back-of-the-envelope calculations, and I thought it would be useful to share a mathematical explanation.
Here's my layman's explanation:
font-size) flexible with viewport units.The code ends up, in one particular example, like this:
@media (min-width: 320px) and (max-width: 959px) {
h1 {
font-size: calc( 1.5rem + 16 * (100vw - 320px) / (960 - 320) );
/* For a negative slope, we have to invert the breakpoints */
line-height: calc( 120% + 3.2 * (100vw - 960px) / (320 - 960) );
}
}Remember there is a PostCSS plugin.
If you're a regular reader here at CSS-Tricks, chances are good that you're familiar with using 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 newly available in Blink-based browser. It gives us the same power found in browser features such as the Font Loading API and third party scripts such as Bram Stein's Font Face Observer. The key difference, though, is that this capability is also now a CSS feature.
It's a big redesign of a site I'm sure all of use have visited many, many times. It even resides on a new subdomain: fonts.google.com.
Live typing samples in the search index for the win! There are also much nicer font specimen pages with clearer examples, cool/nerdy data visualizations, and pairing recommendations. Reminder that you may want to use a bit more sophisticated font loading than the snippets they provide, though.
I ran across this Typography Handbook the other day and thought it was very well done. It gets you right away by looking at two resumes and having your rather instinctively prefer the one with nice type, even though the information on them is exactly the same.
Reminds me of how many other typographic "handbooks" there are:
Dave and I started the latest ShopTalk Show with an audio clip from Tim Brown responding to some of our previous chatter regarding vertical rhythm (and such). Transcription here. It sparked another interesting conversation about these things.
A small part of that was about Tim's coined phrase "molten leading", which is essentially line-height that depends on line length.
I hope you read that title out loud in your best Seinfeld impression.
A recent question in our forums made me aware that there are more properties that can be added to @font-face than the usual font-family and src suspects. What are the point of those? Why would you want to declare other font declarations there?