An Event Apart: Web Type For Developers

by Luke Wroblewski February 17, 2014

At An Event Apart in Atlanta GA 2014, Jenn Lukas outlined how Web developers can work with Web type. Here's my notes from her talk The Developer’s Ampersandwich:

  • Help developers understand design intentions not just specs.
  • Developers love formulas and rules. When it comes to Web type, we had a lot of rules. Web-safe fonts determined what we could use on our pages.
  • Web fonts repositories publish top fonts in use -can we learn from what people are using the most?
  • Use style guides, pattern libraries, and general styles to ensure no type goes un-styled.
  • A heading audit is a listing of all the heading classes on a site (its likely you will have more than 6). This illustrates all the type options people have.
  • Web fonts ave changed everything (for the better). We don't have to cut image headlines anymore.
  • But Web fonts have some cross-browser issues. Set time and budget aside for QA testing.
  • When choosing Web fonts, look at your analytics to see what your audience is using. Make sure things render well on the platforms your audience uses it.
  • Make sure your fonts will work for your audience before design approval.
  • Use an HTML test page instead of a Photoshop comp to share how fonts will look on a page. Things will be different between them.
  • Use -webkit-font-smoothing:antialiased cautiously. You don't need to set across all your pages but perhaps on light text on top dark colors.
  • “Fixing” a problem in one browser can make it more different than other browsers.
  • You should be testing in your least favorite browser.
  • Monitor how Web fonts impact your page speed. Font-face performance can be slow especially on mobile.
  • Don't use all the fonts. Google and Typekit both warn when you add too many fonts to a single Web site.
  • Google Fonts asks you to use less than 160k, Typekit says 400kb.
  • If you are self-hosting fonts, you can use mobile-first defaults to only load styled fonts on more capable browsers.
  • What fonts are available on mobile devices? Check out this chart.
  • Typekit allows you remove support on mobile devices in your kits which cuts down on file size a lot.
  • Icon fonts are like wingdings on steroids. Implementing them is very similar to using to Web fonts. Icon fonts prevent you from having to cut image sprites.
  • Icon fonts are great for retina displays as they are vector art.
  • There are a lot of icon fonts to choose from. Research the tools you're using before committing to it: is it actively being updated?
  • IcoMoon allows you to use their fonts, add your own, or combine them together.
  • Use aria rules for screen readers to make icon fonts to actual letters or make them to private use so they don't get read by screen readers.
  • Contrast should be 4.5:1 to make fonts readable. We might be able to use media queries to support adjusting contrast in situations like low-light.
  • Line lengths on the Web should be capped at 45 to 75 characters.
  • Typecast allows you to create type styles in the browser that can quickly be added to a live site.
  • Plan your designs and text for variable content. Identify pain points for your team to overcome them.
  • Don't forget to update your font services often as they continue to upgrade and improve.
  • Limit your font sizes & create a system. It's never too late to audit and review your font systems to cut down on excessive styles. This helps with performance and ongoing maintenance.
  • Type-o-matic counts all the fonts on a page and orders them by color and size.
  • Use CSS to affect legibility. The invert filter can swap colors fro higher contrast. Or blur to remove focus on less important text.
  • QA, don't design in the browser.