Type E:

From Beyond the Envelope™

 

The font stack issue.

 
Three overlapping cards, each featuring the letter R in a different font.
 

Part of the process of designing an email is choosing what font, or fonts, you want to style your text with. While you’ll always want your first choice of font to be the one your recipient’s email client, webmail client or app renders, that may not always be possible. There may be several reasons for this.

 

Misrendering reasons

Reason No.1

It may be that your first choice of font is a web font, which will only render on email clients that support web fonts, such as Apple Mail on iOS, iPadOS and macOS.

Reason No.2

It may be that your first choice of font is a system font, which will only render on a selection of your recipient’s email clients, webmail clients and apps, depending on whether or not they are using the appropriate operating system.

Reason No.3

It may be that your recipients are using an email client, webmail client or app on a device that only renders a limited family of fonts, such as Droid or Roboto on Android.

 

Given that your first choice of font, or fonts, may not render, you must define a second choice of font or fonts, as an absolute minimum, and possibly a third, fourth and fifth choice too! You define your choices using a font stack, and that’s what I’ll look at in this issue.

What is a font stack?

A font stack is a list of fonts listed in order of choice (e.g. your first choice, your second choice, your third choice, your fourth choice, your generic choice). You define your font choices using font-family in the following format:

 

font-family:your first choice, your second choice, your third choice, your fourth choice, your generic choice;

 

When rendering your email’s text, your recipient’s email client, webmail client or app will render your first choice of font – if it’s available. If your first choice isn’t available, it will move on to your second choice. If your second choice isn’t available, it will move on to your third choice – and so on, until it reaches your generic choice.

Generic choice

The last choice in your font stack should be your generic choice. This choice will render if none of your previous choices are available.

There are five generic choice fonts, and you should use the one that’s the same category as the other fonts in your font stack. For example, if the fonts in your font stack include Roboto (a web font), Helvetica Neue (a system font) and Arial (a web safe font), which are all sans-serif category fonts, your generic choice font should be sans-serif, as follows:

 

font-family:Roboto, Helvetica Neue, Arial, sans-serif;

 

Here are the generic choice fonts, alongside fonts from their respective categories:

  • Sans-serif: Roboto, Gill Sans, Arial
  • Serif: Roboto Serif, Hoefler Text, Georgia
  • Cursive: Parisienne, Bradley Hand
  • Fantasy: Papyrus
  • Monospace: Roboto Mono, Courier New, Courier
 

If you don’t include a generic choice font, and none of your other choices are available, you run the risk of your recipient’s email client, webmail client or app rendering your font or fonts in a font from a different category.

Web safe fonts

It’s worth stating, that if your choice of font is web safe (e.g. Arial (sans-serif), Georgia (serif), or Courier (monospace)), it, by its very nature, will render for your recipients. However, there are some exceptions to this. Even web safe fonts, such as Arial, will render as Droid or Roboto on Android, as it only renders the fonts available to it on its operating system.

Creating your font stack

How you go about creating your font stack will depend on the type of fonts you want rendering in your email. Let’s look at some examples:

 

Example 1: Web safe + Generic

 

font-family:Arial, sans-serif;

This is perhaps the simplest and safest, as web safe fonts will render on most email clients, webmail clients and apps. Where they won’t (e.g. Android), your generic choice will render the font in the correct category (e.g. sans-serif).

 
Arial.
 

Example 2: Web font + Web safe + Generic

 

font-family:DM Sans, Arial, sans-serif;

Where your first choice is a web font, your second choice is a web safe font, and your third choice is a generic font, in case your web font doesn’t render.

There are two reasons why your web font may not render. One, your recipient’s email client, webmail client or app may not support web fonts. Two, your recipients may have a poor internet connection – or none at all. In that case, they’ll be unable to download the web font from its host server.

 
DM Sans.
 

Example 3: System + Web safe + Generic

 

font-family:Gill Sans, Arial, sans-serif;

Some brands define a system font as their first choice. John Lewis is an example of this.

John Lewis use their own bespoke web font, ‘GillSansforJL’, on their website but don’t use it on their emails. Instead, they utilise the version of Gill Sans that’s installed on their recipient’s operating system.

In this way, John Lewis achieves brand consistency across email and web without needing to implement web fonts on email and, in the process, reduces download time, not to mention cost.

 
Gill Sans.
 

Positioning your font stack

Inline CSS

For the most part, font stacks are best positioned within inline CSS, within table cell styling or within typographic element styling:

 

<td style="font-family:Arial, sans-serif;">

 

Elements contained within the <td> element inherit the font stack applied to it.

Font stacks applied to elements contained within the <td> element (like this <h1>) will override the font stack applied to the <td> element:

 

<h1 style="font-family:Georgia, serif;">

 

Internal CSS

You can position font stacks with web fonts within internal CSS in the <head> of your email. When accompanied by an !important declaration, it will override the internal CSS applied to elements within your email:

 

<style>
p {font-family:DM Sans, Arial, sans-serif !important;}
</style>

 

This method allows you to change the web font you’re using in one place without changing all the inline CSS, as the same email clients, webmail clients and apps that support web fonts also support internal CSS.

Getting creative with font stacks

While my approach in this issue has been to ensure categories are consistent throughout font stacks, you can get creative. An example of this is Type E: itself when I style it with a Featured Font.

Those opening Type E: with an email client, webmail client or app that doesn’t support web fonts, will experience it with Arial and Courier – the web safe fonts applied using inline CSS.

Those opening Type E: with an email client, webmail client or app that does support web fonts will experience it with a Featured Font, which may not necessarily match the category of the font it’s replaced.

 
 

Conclusion

  1. While HTML editors will present you with a list of preselected choices for your font stacks, don’t implement them without first asking yourself whether they meet your requirements.
  2. Carefully consider your requirements. You may only need a web safe choice and a generic choice.
  3. Consider using system fonts where appropriate. Fonts like Roboto on Android and Gill Sans on Apple iOS, iPadOS and macOS.
  4. Position your font stacks appropriately, using inline CSS for web safe fonts and internal CSS for system fonts and web fonts.
  5. Document your font stacks within brand guidelines so that they can be consistently implemented at scale.
 
 

Made with Envelope Developer™

Powered with Parcel logo.

 

Type E: is an email created by Email Designer and Developer, Paul Airy.

You’re receiving it because you subscribed on the Beyond the Envelope™ website. If you’d like to change your preferences, select the ‘Update preferences’ button.

 
Update preferences →
 
Unsubscribe →
 
Subscribe →
 

Type E:

 

Copyright:
© 2023 Paul Airy / Beyond the Envelope™
All rights reserved.

 

View in browser

 

F.F.