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?

Why Inline?

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:

::first-letter

::first-line

:active

:focus

:hover

:link

:visited

From CSS2, we do not support:

:first-child

:lang

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?

8 Comments

One question. For the PHP API implementation, should camel case be used for the “inline_css” option?
e.g. [
inlineCss => true
]

Dave Grayon Mar. 23, 2016 at 9:40 am

The php-sparkpost library does support this option in master, not in any of the releases at this time.

Yes, this option follows the same convention, so camel case should be used.

Johanneson Mar. 23, 2016 at 6:18 am

is this also possible with the SMTP method of sending e-mails?

Dave Grayon Mar. 23, 2016 at 9:42 am

Yes, good question, you can enable inlining by adding an X-Header to your mail:

X-Msys-Inline-CSS: true

Samon Jun. 8, 2016 at 3:03 pm

Does anybody know if the not supported selectors remain in the head?
That way you can provide :hover for those people using a client that supports CSS from the

Jennifer Cooperon Jun. 9, 2016 at 11:28 am

Hi Sam!

We don’t remove css from the html, so everything stays in the head. If you have other questions, please check out our community slack channel, our team hangs out there and you can chat with them in real time.

Thanks!

Fabon Dec. 9, 2016 at 1:11 am

Hi, how does your system handles css @media max-width/min-width, for responsive design ?

I know some email inliner do inline them (but that’s wrong..), the best thing is that the inliner ignore them, but let them in header. (so some email readers like Gmail or Apple mail will use them)

We use cookies to optimize your experience, analyze traffic, and personalize content. To learn more, please visit our Cookie Policy. By using our site without disabling cookies, you consent to our use of them.