System Fonts in SVG

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.


“OpenType Variations Fonts”

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.

The Math of CSS locks

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:

  1. You can make a value (like font-size) flexible with viewport units.
  2. Using just viewport units, that value might be too flexible, resulting in values that are too small or too big.
  3. You can "lock" the upper and lower limits with @media queries.
  4. You still need a fancy calculation to calculate the "middle" values between the two "locks".
  5. The calculations can vary in complexity, especially when trying to use relative units and accommodate user font scaling.

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.

`font-display` for the Masses

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.


Google Fonts Redesign

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.

Typography Handbook(s)

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:

Using Web Fonts at All: Point/Counterpoint

Adam Morse makes the case against webfonts:

Typography is not about aesthetics, it’s about serving the text. If even a small percentage of people don’t consume your content due to a use of webfonts, your typography is failing.

All this being said I care deeply about aesthetics, and I’ve found the following two sentiments to be true: System fonts can be beautiful. Webfonts are not a requirement for great typography.

I’ve argued in their defense. Also, I reveal a lot of my own biases as a type geek:

I don’t believe that all of human experience can be elegantly communicated via Helvetica, Times, Georgia, or San Francisco. And when I read that “typography is not about aesthetics” then I sigh deeply, heavily and come to the conclusion that 1. yes it is and 2. aesthetics is a problem for the reader. The more ugliness that is pressed upon us, the more lazy we become. Beauty, legibility, subtlety, these are the qualities that are possible with the help of web fonts and without them we are left with a dismal landscape devoid of visual grace or wit.

Use `rem` for Global Sizing; Use `em` for Local Sizing

Richard Rutter’s guide for setting the font-size of an element is interesting: he argues that we should use both em and rem units depending on the relationship it might have with other elements on the page:

Take the example of a pull quote containing two short paragraphs. The spacing between the paragraphs will depend on the size of the paragraph text, so you could feasibly set that spacing in either rems or ems. Should you decide during your design process that the pull quote should be set a bit larger, then the spacing between the paragraphs must also be increased. Therefore the paragraph spacing is directly related to the paragraph text size and therefore be considered local sizing within a component. Hence you should use ems in this case.