TL;DR – add “inline_css”: true to your Transmission Options object.
If you’re reading this blog, you probably know a thing or two about email. What’s tricky about email is that there are more than a few things that need to be just right in order for your customers to be able to interact with what you send them. One of those things is CSS inlining, and it affects how your HTML email is rendered in many email clients – is that white text on a blue background, or is it invisible?
The easiest way to understand why CSS inlining matters is to think about how a web-based email client displays HTML messages. In that scenario, the email client itself is built in HTML, and is already using CSS for various things. So how can the email client display HTML messages, without allowing the style rules within each message to affect the display of the email client itself? The simplest and most consistent approach is to remove any CSS rules, which leaves only style attributes on each individual HTML tag, AKA “inline styles.” This is the approach that many email clients take, especially web-based email clients.
So that’s the “why” part of CSS inlining. What about how? SparkPost runs on the Momentum platform, which includes several libraries that make the inlining process easier. CSS inlining has been on our radar for a while, which included building several proof-of-concept implementations, with a variety of approaches. We’ve recently received lots of requests for this feature, which bumped its priority on our roadmap. Voilà!
How to Enable Inlining with SparkPost
Enabling automatic inlining is a simple change – add “inline_css”: true to your Transmission Options object, and send as usual. We didn’t see a significant increase in generation time during our performance testing of this feature, however it is possible that your special CSS may cause generation to take longer than usual.
Inlining and Advanced Templating
SparkPost offers templating features that can change the structure of HTML messages, such as conditional content (if /then /else ) and dynamic per-recipient content. Our CSS inlining is fully compatible with these templating features, since inlining happens for each individual message, after template processing has been completed.
Selector Support (CSS1, CSS2, CSS3, Oh My!)
There are lots of types of CSS selectors, and they can also be combined so that, for example, the color of an element changes based on the element(s) that contain it. SparkPost’s CSS inlining support covers most common usage for email, with the following exceptions:
From CSS1, we do not support:
From CSS2, we do not support:
Some of these are excluded because it is impossible to support them correctly (:active , etc). Others because they are simply shortcuts – p:lang(en) can also be written p[lang=”en”] .
Support was also added for some CSS3 attribute value comparison operators:
- [attribute^=”value”] – “begins with”
- [attribute$=”value”] – “ends with”
- [attribute*=”value”] – “contains”/”substring”
Did we miss your favorite CSS selector? Which one, and how have you used it with email?
Have you been inlining for ages? How can we make your workflow easier?
Or did the world just become a little more complicated when you learned that CSS inlining was a thing?
If you liked this post, check out Advanced Email Templates