Best method for using Adobe TypeKit in email
So I'm aware there's been a fair bit of research into what is the best method to include web fonts in email based on the support for things like @import
<link>
and @font-face
. The consenus seems to be @font-face
is the way to go. More recently Adobe TypeKit allowed a font kit to be embedded via pure CSS. Previously, their implementation was JavaScript based which was out for email. I know Google Fonts, did work, but it doesn't have some of the fonts TypeKit has.
Up until now, I had been using @font-face
to serve a font I use for my organisation, as we have a web license for it that permits self hosting in addition to being hosted on TypeKit, however given we also have the custom font implemented on a TypeKit, I've been considering trying to use TypeKit directly in our email campaigns, as we have enough quota in addition to our website usage.
The first problem to me seems I'd have to give up @font-face
because TypeKit does some serious obscurification on the font files looking at the CSS. Likewise by directly copying the @font-face
rules in the kit provided, it means any changes made to stylesheet on the TypeKit side will not be reflected and probably break in templates.
How does @import
and <link>
hold up with email clients that support web fonts these days?
James,
Adobe's documentation on it (here) outlines using
@import
, but we have been using TypeKit in some of our emails for a few months and have found the<link>
approach to work a bit better.It's sort of a toss-up from the support end between
@import
&<link>
, but Litmus has a good blog about import methods that states the support is a little better for rel stylesheets. Main takeaways from last reading were:@font-face
when you're self-hosting or using Google Fonts@import
has good support, fonts are loaded after email<link>
has slightly better support and fonts are loaded inline (my preference, since our kit is pretty lean — only 2 weights)Few other notes on TypeKit, since I had to get into the weeds with our Web Design Manager on the topic:
Good luck!
Hi!
I am a little confused, I thought that typekit fonts will work only on the domains that you add to your Kit, so yes if I add Litmus, you can test them, but when they get sent out and opened on gmail, will they still work?
@D_Buda
Well, no web-fonts work in Gmail (accept for Roboto & Google Sans because of the new UI), but yes — where supported, TypeKit fonts will load in email clients the same as
@font-face
. You only need to include domains to the kit you might be using for testing/development (litmus.com to view in Builder, localhost for local development, etc., and your ESP's domain for viewing previews).Thank you for the explanation, that is very good to know and it means I can use typekit in my current project!
Support for
<link>
is similar to@font-face
. In fact, I couldn't find a client where@font-face
worked and<link>
didn't. Here are my findings with the three methods:Works
Apple Mail
Outlook (Mac)
Android 4.4
iOS Mail
Outlook Android (Link only)
Samsung Mail (Link only)
Doesn't Work
IBM Notes
Lotus Notes
Outlook (Windows)
Thunderbird
Android 5.1, 6.0
Gmail App
Gmail IMAP
AOL
Comcast
G Suite
Gmail
New Gmail
Inbox by Gmail
Office 365
Outlook.com
Yahoo!
Just make sure to wrap the
<link>
tag in outlook conditionals.Definitely! Good point on the conditionals. Additionally, we wrap the font-family declaration in a
@media
query to double-down on it being ignored by Outlook. Litmus covers both of these techniques in their blog post, linked in my comment above.Beware if you're using Pardot and
<link>
as Pardot tracks links that begin withhttp://
orhttps://
, so links such ashttp://fonts.google
... get rewritten and tracked.👆🏻Another good reason to be using the
@import
or@font-face
methods, since it looks like Pardot does not rewrite links wrapped in embedded CSS styles.I would be shocked if they didn't also offer some HTML attribute that disabled tracking on specific links. Silverpop used to have an
xt="notrack"
param and in our current ESP (Listrak) you can wrap links in their#Listrak\NoTrack#
system tag to disable tracking/link transmogrification.I should probably update my original post since we've moved solely to
@import
as Outlook now seems to strip out<link>
tags in the head.