CSS-Tricks

webfont

Critical Web Fonts

# By Robin Rendle

Zach Leatherman outlines a new method for loading webfonts whereby the process can be broken up into two stages:

...instead of a full Roman webfont in the first stage, it loads a small subset of the Roman webfont, in this case with only the uppercase and lowercase alphabetic characters.

Then, in the second stage, we can load all the extra parts of that font, such as numbers or special characters. Ultimately, this greatly decreases the time in which readers will see the switch between the fallback font and the fancy web font: the first stage is only 9kb in size, which then gets replaced with a complete 25kb version.

The difficulty here being that a lot of type foundries don’t provide developers with the option to subset a font file.

TypeKit Starts Using Native Font Loading API

# By Robin Rendle

Typekit has updated the WebFont Loader project with support for the new CSS font loading API:

Before the introduction of the native API, we detected font loading by inserting test elements in the page. These elements were regularly polled for width to see if the font had loaded. This process is very expensive because it triggers a page wide style reflow each time the elements are checked. Using the native API, we can bypass this process completely, which results in a big performance improvement.

Always nice when browsers step up and help make things better and faster, especially when there was demonstrably high need, and then see major vendors make use of it right away.

Webfont stuff is a fairly regular topic around here, feel free to browse around.

Caring about OpenType features

# By Robin Rendle

Type aficionado Tim Brown has written a great piece about how to make typographic enhancements with the OpenType features of a web font. These additions can be subtle, such as ligatures and small caps, but other tools such as kerning or contextual alternates can often have a big impact on the overall reading experience:

More than fancy swashes and superfluous ligatures, OpenType features are font superpowers. The best, most capable typefaces are full of sophisticated reasoning and delightful surprises — things that are often integral to the design of the type itself, or that help it work better for specific typesetting tasks.

Creating a Web Type Lockup

# By Chris Coyier

A type lockup is a typographic design where the words and characters are styled and arranged very specifically. Like the design is literally locked in place. This idea is slightly at-odds with the responsive web that we know and love, where text is fluid and wrappable and whatnot. Yet, the design possibilities of lockups are very appealing. I think we can hang onto what makes them awesome while still holding onto what makes the web awesome.

(more…)

A New Responsive Font Format for the Web

# By Robin Rendle

Nick Sherman gave a fascinating talk at Ampersand earlier this month which was based on an article he wrote called Variable Fonts for Responsive Design. In both the talk and the essay he suggests that we need a new font format to solve complex responsive design problems:

…the glyph shapes in modern fonts are restricted to a single, static configuration. Any variation in weight, width, stroke contrast, etc.—no matter how subtle—requires separate font files. This concept may not seem so bad in the realm of print design, where layouts are also static. On the web, though, this limitation is what I refer to as the “glass floor” of responsive typography: while higher-level typographic variables like margins, line spacing, and font size can adjust dynamically to each reader’s viewing environment, that flexibility disappears for lower-level variables that are defined within the font. Each glyph is like an ice cube floating in a sea of otherwise fluid design.

(more…)

Loading Web Fonts with the Web Font Loader

# By Robin Rendle

Several years ago the consensus on font loading in the community was that, as a website loads, all fonts should be hidden until the correct resources have been downloaded. Many designers and developers argued that the default font loading method called the “Flash of Unstyled Text”, or FOUT, was an annoyance to users. This is when the fallback web font, say Georgia, is shown on screen first then replaced by a custom font when it loaded. They argued that it would make for a more cohesive browsing experience if users simply waited for everything to download instead of experiencing this flash from one typeface to another.

But today this is not the case.

(more…)

font: caption;

# By Robin Rendle

Joe Richardson shared this little trick over on CodePen:

body {
   /* operating system font  */  
   font: caption;
}
  • If you're on Ubuntu this will be the Ubuntu Font.
  • If you're on Yosemite this will be Helvetica.
  • If you're on El Capitan this will be San Francisco.
  • If you're on Microsoft this will be Segoe UI.

Not entirely sure the support of this, but if it works for your needs it's a lot easier than declaring them directly or sussing it out with JavaScript.

Update: Viljami Salminen has done a lot more testing on this and it looks like there are a few problems in iOS. Make sure to check out his Pen for more info.

The @font-face dilemma

# By Chris Coyier

Chris Manning takes us through the weird journey that is custom fonts on the web. We started with the "Flash of Unstyled Text", which at first we didn't like because it was abrupt and felt janky and could even cause reflow, which didn't help readers focus. Browsers reacted, and started hiding text until the custom font was ready (various implementations did it differently). "Flash of Invisible Text" as it were. Times have changed such that FOUT is now preferable again, because at least you could read something immediately. Chris shows how you can get that back through various JavaScript methods.

New to me: the future holds native browser methods to give us more control. A font loading API and a CSS font-display property.

I Left My System Fonts in San Francisco

# By Robin Rendle

A post by Craig Hockenberry that details how to use the San Francisco system font for your website if you're running El Capitan.

I especially like Craig's suggestion for a new syntax when using any operating system's font, so for example in iOS that would probably be San Francisco or Helvetica Neue whilst in Android it would be Roboto. He suggests that we declare a system keyword in the font-family rule (although this won't work in any browsers today):

body {
 font-family: system, -apple-system,
     ".SFNSDisplay-Regular", HelveticaNeue, LucidaGrande;
}

The ability to have a standardised way of doing this sounds like a good idea to me.

Related: through JavaScript, we can figure out the system font and apply it.

icon-anchoricon-closeicon-emailicon-linkicon-logo-staricon-menuicon-nav-guideicon-searchicon-staricon-tag