Here at Scarab Research (now part of Emarsys) we usually go to “hack weeks” twice a year. We rent a nice house with a pool and a large living room, grab our computers and work on things that are not strictly connected to our daily job. We try to find new ideas, relax, and have fun.
I read a great article on the Litmus blog about How to Code A Live Dynamic Twitter Feed in HTML Email and I was wondering: are there any other ways to inject dynamic content into emails? These injections are crucial because they let us decide what to display in the email at the time of opening of the mail, not at the time of sending. I loved this idea so much, so on our latest 2017 Hack Week I picked this topic.
The most trivial way is using images, just as we do it in our daily job: you render the images when the email client requests the image. It’s a common approach and working fine for most email clients. What else may email clients download at the time of opening the email? CSS files, SVG, and font files. I was wondering which one of these would be exciting for a “hack week” project, and I decided FONTS of course! One of my colleagues was experimenting with SVGs in the meantime, which is also exciting, but that’s another story. I was focusing on web fonts and I came up with an idea of feeding dynamic content into font files. It’s not difficult, here is the recipe.
1st step: Create an HTML email with a unique sequence of characters like this one below. Here I pasted the characters as HTML entities, starting from code 192 and pasted 255 characters.
2nd step: Apply custom CSS rules to this <span> like this:
3rd step: The tricky part comes now. When the email is opened, the email client downloads the font file, which will contain the dynamic content by mapping the glyphs of the content to unique character codepoints. So, let’s say we want to display “Hello World”, then we should generate a font file where the mapping is the following :
4th step: Check the rendered emails in various email clients, with the help of Litmus.
You can see it in action here as well, if your browser supports web fonts. And that’s it, as simple as that. However, this solution has many shortcomings if we dig deeper. Some of them are addressable, some of them are not.
-
- Dynamic content has limited length: in this example we generated an email with 255 characters, so our content has to fit into this size. In fact, the Unicode range is big enough, so this can’t be a real problem, unless we want to feed a whole book.
- There are tricky control characters: you should choose your Unicode range carefully. I found some characters which were not rendered with our custom glyph.
- Word breakings: in this concept there is one long word only, so the email client can’t break it into rows. We can solve this by generating an email where we predefine that our text block can only contain a maximum of X words, and each word can be a maximum of L length. So our email will contain blocks divided by spaces, for X = 3 and L = 6, our Hello World example will look like this:
- Copy & Paste problems: text copied to the clipboard will be garbage. We can just avoid copying with the help of user-select: none; CSS property.
- Fallback: detecting that the Web Font is not downloaded is not easy and actually most of the clients don’t support Web Fonts at the time of writing. I came up with a solution which can prevent the garbage characters from appearing to the client. It’s a sneaky solution, but I’m proud of it. The idea here is that we set the size of the font from CSS to very small, like 0.4px, then we create a font file with huge glyphs. If the font is not downloaded, the garbage text won’t be displayed, but if it’s downloaded, it will look fine. See scaled.html for a demo. I’m sure there are more sophisticated solutions and this one might not work for every client, either.
So what is it good for? This way we can put dynamic text content into emails, not images, which has many advantages over images and will render better in email clients. The next wholly legitimate question is: where does this work? I haven’t done any deep research yet, but here’s a quick list where I’ve seen it work. Unfortunately, Google Gmail and Inbox won’t be in the list in any platform or browser.
- Android 4.4
- Apple Mail
- Outlook 2011 (OS X)
- Outlook 2016 (OS X)
- iPhones
- iPad
I’ve made a repository called webfontrecos on Github, with code samples so that you can play with it. I used Serverless to create a Google Cloud Function which will generate the font files. In this example a random book title is chosen and feed into the web font.
I have really enjoyed learning about Fonts. In the above experiment I generated fonts for emails, but it is working in browsers, too, where the support is much better. I am convinced that there are still lots to explore. I hope it was inspiring, feel free to leave a comment below.
This article originally appeared on the Emarsys Craftlab blog.
