New Book Sample: Typography in Email
This is a sample from my new book, Professional Email Design, that launches on January 15th. Sign up for my email newsletter to receive information about the book and get notified when it’s available for purchase.
There’s an old article from the design studio Information Architects that makes a great point:
Web design is 95% typography.
As an offshoot of web design, the same is true about email. No matter what your message, you need to be able to communicate it clearly using type on screen. Clear type is only half the battle, though. We want to make email a delightful experience for our subscribers, so making that type beautiful and enjoyable to read is our ultimate goal.
This chapter takes a look at how to apply styles to your text, how to make those styles work well across email clients, using web fonts in email, and avoiding any major bugs.
Applying Styles to Text: Part 1
I mentioned earlier in the book that some designers insist on using semantic elements in their HTML. They mark up headlines using
h3, etc. tags. Paragraphs are naturally wrapped in
p tags. Unless accessibility is absolutely necessary, I typically recommend avoiding this method. Every rendering engine has its own way of styling those elements and, if you want your email to look similar everywhere, you will necessarily have to override those default styles. The semantic way leads to writing a lot more code and, usually, the required step of running that code through an inliner.
An inliner is a tool that takes CSS written in either an external stylesheet or in the
head of an HTML document and moves that CSS inline on individual HTML elements. There are a ton of inliners out there, and most work well. However, I prefer to hand-code inline styles so that I can a) keep the code clean and b) know and understand every piece of my email template. Also, I don’t trust the robots. If you are interested in using an inliner, the tools section of the appendix has suggestions on a few.
So, if not on heading or paragraph tags, where do we apply styles? Let me introduce you to arguably the best email designer in the world: Kevin Mandeville. Kevin is the email designer at Litmus and consistently blows people away with what he does in the inbox (think stuff like CSS animations, SVG, Video backgrounds, product tours IN THE INBOX). He also has a saying that every professional email designer should have tattooed on their forehead.
If you ask him, he’ll say the GTFO stands for get to fixing Outlook. But we all know what it really means…
<td> or GTFO means that nearly all of our styles should be applied to table cells. We’ve seen this applied when talking about structural padding and alignment in the last chapter, now we’ll look at how table cells are used to style content. They’re our bread and butter, so get used to applying everything there. Following that logic, all of our text will exist directly within a table cell.
So, any styles we want that text to have are slapped right on the table cell.
This approach will be applied to all of our text with the exceptions of:
- Links, which will be styled using the anchor tag. We’ll get to those later.
- Text within a section that needs special styling, which will be handled with the
- Things like dates, times, phone numbers, etc. that some email clients insist on making links. We’ll talk about those in Chapter 3.
To cover our bases, if a table cell contains text, it should always have the following styles defined:
Even if you are using normally weighted text or the same font family as other copy, you can’t rely on table cells inheriting styles from a parent. Let’s look at an unstyled block of text:
Let’s say we want to make the text lighter, use a sans-serif, increase the size a bit, and add some line-height to make the reading experience more comfortable. We can accomplish this with the properties listed above:
That’s better, huh? You could just copy and paste that formula into all of your emails, but then you wouldn’t learn anything, would you? Let’s take a look at each of those properties and see which kinds of values should be used.
color property controls the color of the text inside an HTML element. It accepts a variety of values, including:
- The CSS color keyword (e.g. red, yellow, blue).
- A three-character hexadecimal value (e.g. #f00 produces red).
- A six-character hexadecimal value (e.g. #ff0000 also produces red).
- An RGB or RGBa value (e.g. rgb(0, 0, 0) produces black, rgba(0, 0, 0, 0.5) produces black at half opacity).
Like most other things, these all work on the web but not in every email client. The safest way to declare colors in HTML email is by using the six-character hexadecimal value. Therefore, anytime a color is declared in this book, it will take the form:
Some email clients, typically ones which use the Webkit rendering engine, can handle the other methods, too. If you know your audience is largely opening emails in Webkit-based email clients (Apple Mail, iOS Mail), then you can use something like RGBa, which is useful for adding transparency to text.
font-family property controls what typefaces are used to display text. If left undefined, operating systems and email clients will default to system fonts (e.g. Times New Roman, Arial, Georgia, or Lucida Grande) that come installed on most systems. You should absolutely define a font stack–an explicitly stated preferred ranking of fonts–for your text.
A font stack allows you to declare back up fonts for when a preferred font isn’t installed on a computer or, in the case of web fonts, is unable to be downloaded. When declaring your font stack in the
font-family property, you put your preferred font first, followed by increasingly generic backup options:
In this instance, if Futura is installed, text will be displayed using that font. In Futura’s absence, it will then fall back to Trebuchet MS first, Arial second, and whatever sans-serif font is installed as a last resort.
You will notice that Trebuchet MS is surrounded by quotes. This is because it consists of two separated words. Many fonts have complex names and, if they include spaces, will need to be wrapped in single quotes. This handles any email clients that can’t properly parse spaces in the
We’ll revisit the font stacks when we start talking about web fonts. Until then, keep this in mind:
Font stacks allow us great control over the most important aspect of our campaigns. You should never allow the system or an email client to make design decisions for you. Always declare a decent font stack, even if it’s a simple one.
On the web, there are a number of ways to declare font sizes. You can use keywords like large or xx-small, fixed values like px, or relative values like ems and rems. Since we’re working towards always building responsive emails, you would be right in thinking that relative units like
rem would be ideal. However, a lot of email clients don’t understand font sizing unless declared using pixels.
Therefore, all of our font sizes will use the
You can make that font size as big or little as you want, but you should keep a few things in mind.
First, some mobile devices (looking at you, iPhone) automatically resize text that is smaller than 14px in an effort to make it easier to read on smaller screens. Anything below 14px will be resized to 14px. So, if you’re using small text for something like a disclaimer, you will need to account for this in your code or risk your design being broken.
This can be accomplished by using the
text-size-adjust CSS property, prefixed for the appropriate rendering engine. Webkit on iOS is the main perpetrator, but Windows Mobile does something similar. As an example, we can target both. You can do this in one of two places:
As a style reset in the
head of our document:
Or inline on an element in case the
head is stripped out of the document:
Secondly, you should use a comfortable font size for all readers. A good baseline is to have text around 16-18px. This is big enough for most readers to easily read, while not being so big it only allows you to fit 20 characters on a line.
Finally, don’t make your text too big. While you want your headlines to stand out from your body copy, don’t make them absurdly massive. Use other tools like
color to create hierarchy, in tandem with
When we look at making our emails responsive, we’ll come back to
font-size and see how we can change the size of our type on different devices.
font-weight property allows you to specify how heavy a font should appear. The weight refers to how thin or thick the lines that make up letters are. A great typeface will have a lot of different weights available. Other typefaces will only have one or two.
A font’s weight can be declared using either a keyword (e.g. normal, bold, bolder) or a numerical value (e.g. 100, 200… 900). In most cases, you will likely only use the normal or bold keyword. However, if you are using a typeface with a lot of variations, say Proxima Nova, you may want to rely on numerical values for font weights, since it allows greater flexibility of design and access to all of the available weights.
Let’s say we have a large headline set in a thin variation followed by some smaller body copy that needs to be set in a medium weight. You can mark that up like so:
The typical design will likely call for a bold headline and normally weighted text. This is where you can simply use keywords:
Both approaches are perfectly valid, it all comes down to how specific you need to be with weights and whether you want to keep track of a bunch of number values or a few keywords.
line-height property allows you to specify the amount of space between lines of text. Again, you can specify values a few ways, including a unitless number, fixed values like
px, and relative units like
On the web, it is common practice to declare line-heights using a unitless number to avoid inheritence issues and unpredictable results. Unfortunately, not all email clients understand unitless numbers. So, your safest bet is to use a pixel value when setting the
line-height property, like so:
The space between lines has a very real correlation to how easily we can read text. If text has too little space between lines, it feels cramped and uncomfortable to read. If there is too much space, lines start to feel disjointed.
line-height of a block of text works in tandem with the
font-size of that text, as well as the width of the block of text itself. Typically speaking, smaller text should have larger line-heights, while larger text can afford to have smaller line-heights. My general rule of thumb is to have the
line-height four pixels larger than the
font-size for most normal text. For headings, that will drop to either equal that value or even be two or four pixels smaller than the
font-size value. However, you should always test out different line-heights in your designs to see what feels comfortable to read.
While not mentioned above as an absolutely necessary style to apply, another useful CSS tool is the
font-style property. This property allows you to specify one of three variations of a font: normal, italic, or oblique.
Without declaring a
font-style, text will be displayed using the normal value. Both italic and oblique are a means to a similar end in that they will slant a typeface. Italic fonts typically use a properly designed, italic variation that is included in a typeface. Oblique fonts rely on skewing the regular version of a typeface to create slanted fonts.
You will likely only ever use the italic value to make your text you know… italic. This can be useful to provide emphasis on a word or phrase, or to set a particular section apart from the surrounding text, for example, in a photo caption or a disclaimer.
Want to read more? Professional Email Design will be available for purchase starting January 15th.