@font-facewhen you're self-hosting or using Google Fonts
@importhas 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)
- Make sure you add localhost, litmus.com (if using Builder), and any local server to the Kit so you can see fonts in your dev environment
- Consider the impact that email opens have on the pageview allotment per your TypeKit plan (if also using on web — emails are extra PVs!). I actually opened a thread with support to try and get a clearer answer on this and they updated their knowledge base after the fact. It's still a bit gray IMO and with Adobe's licensing model, this could be a barrier to some based on list size/volume/budget. Also, my understanding is their reporting do not yet allow you to break out email vs. web usage monthly. 👎🏼
- Shame your design lead for not using a Google Font & saving you all this headache. 😉
A place to start is by taking an inventory of your current production process.
Identify the most time-consuming, repetitive tasks — whether that's asset preparation and optimization, copy and content, or spinning up templates from (hopefully) your library of snippets and partials. It's much easier to approach things in chunks and learn ways to batch or automate those, rather than expecting to automate your entire process in one fell swoop. Work up to that.
Once you know your biggest bottlenecks, you've got options. If it's related to Adobe products there are scripts and image processors. For templates, you might want to adopt some task runners like Gulp or Grunt to handle the tedium of compiling css or optimizing images, or sending tests to your favorite QA platform.
A bunch of email geeks have written on the subject and many have built and shared open-source tools like:
In addition, a lot of tools like Litmus and EOA have aspects of this built in for snippet/partial management, which can speed things up and streamline maintenance.
Another step from there, might be ultimately rolling your own build tool, based on a static site generators like Jekyll (ruby), Eleventy (node.js), and others. Personally, we've been using a mix of Jekyll and Python for almost a year to build certain emails with our content editors working directly in a Google Sheet and we pull their content into templates via Google's API, then Jeykll handles the build and inlines our css too. The thing to remember is that automation can sometimes come with a significant upfront time investment (and can be frustrating along the way!) but the time you'll save on the other side, plus the lack of errors, and ease of maintenance will pay off with interest.
Always happy to geek out more on the topic. Find me on Email Geeks Slack.
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).
👆🏻Another good reason to be using the
@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.
It's a little hard to parse the code above in this format, but looks like you might be encountering some of the DPI scaling problems common to Outlook 2013 (and other versions). Have a look through this article by Courtney Fantinato, Correcting Outlook DPI Scaling Issues, which provides some pretty clear steps to take to help resolve VML issues and generally make your backgrounds more bulletproof.
One thing to try right off the bat, would be changing
type="frame" on the
If possible, you should put your full email into Builder and share that link here so others can help troubleshoot.
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.
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
<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:
Few other notes on TypeKit, since I had to get into the weeds with our Web Design Manager on the topic:
This is an issue I've just recently had to address as we brought in our second developer to work alongside me. It really highlighted how both from a training and maintenance perspective, we needed a streamlined approach to sharing and versioning email source files. Git is the answer.
Assuming, like me, you weren't employing any source control best practices when you were the sole coder, Git seemed a bit daunting at first. I've leaned on our engineering and web team's experience & norms heavily, but the principles of Git are super logical once you wrap your head around it. Atlassian has some nice Git tutorials I would recommend checking out/sharing with your team. We are now able to develop on projects concurrently without duplicating efforts, loosing work or breaking any of the existing templates. Just make sure you establish some conventions and norms — and stick to them! For example: we use different branches for new concepts, building with production-ready code, and maintain the 'master' trunk branch as the archive of everything.
The greater challenge, going beyond fully-compiled HTML versioning, is how best to manage your snippets and keep them synced/shared across multiple devs. This is a work-in-progress for us as there's no one-size-fits-all approach depending on the nature of your code, development style, and what IDE(s) your team is using. Personally, I love using Emmet, which is supported by tons of IDEs and just last week found that I could point the Emmet extension folder (in Brackets) to a Git-tracked directory on each devs' local machine. It's not perfect and JSON requires a bit more care when it comes to managing/updating snippets due to the syntax, but it's got us coding pretty efficiently for the time being. Next phase will be partials, Sass, and a task runner to compile/build all the HTML & CSS.
As Jaina mentioned, Builder already has this functionality built in... so you might consider using that as your "build system" to compile your HTML and CSS to start each campaign, then you could always export the HTML to your desktop-based IDE if there was further customization needed.
Anyway, it's a hot topic right now, and as you can tell I'd be pretty interested to hear where you end up — so keep us posted!
If not by way of an app (which it does not look as though it's obviously a third-party) they could be using an API of their own to create a dynamic image, which appears be token-ized per the user, via some custom parameters at the end of the source path.
Here's the complete image tag from an notification email I received this week:
<img alt="LinkedIn" border="0" src="https://www.linkedin.com/comm/dms/logo?midToken=AQEAbDS60hzUFQ&trk=eml-email_notification_single_search_appearance_01-null-9-null&trkEmail=eml-email_notification_single_search_appearance_01-null-9-null-null-177dyy%7Ejar67ah9%7E91-null-comms%7Ebadging%7Edynamic&lipi=urn%3Ali%3Apage%3Aemail_email_notification_single_search_appearance_01%3BWm%2FdutMeQduePeHnJ8bb5w%3D%3D&_sig=2cAXEIMlmrEo01"
Any LinkedIn insiders care to spilll the beans? This would be an awesome write-up for Medium or the Litmus community. I'd imagine @Kevin Mandeville could guess more into what magic might pull this off from his work on the #LitmusLive twitter feeds in email the past few years. Very cool stuff!