Automatic CSS Inlining with SparkPost

Dave Gray
Mar. 18, 2016 by Dave Gray

css inlining

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?

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?

Come chat with us on Slack or Twitter, and let us know what you think.

-Dave

If you liked this post, check out Advanced Email Templates

8 Comments

  • Great, nice to see the new features rolling out at a good rate.

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

  • 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.

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

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

    X-Msys-Inline-CSS: true

  • 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

  • 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!

  • 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)

    So what happens with your inliner if we use @media in css ?

    Thanks

  • Hi Fabrice,

    Our inliner leaves your css intact. During processing, all at-rules, including @media blocks, are ignored.

    If you have other questions on this, feel free to post them in our community slack channel!

    Jen

Related Content

How to Determine the Subaccount ID from a Subaccount API Key

For ESPs needing to determine a subaccount CID to pull analytics data from SparkPost, this hack allows you to do so using the subaccount API.

read more

Bouncy Sink Part 2: Features, Configuration and Installation

We introduced the bouncy sink to test mail traffic patterns, now dive deeper into features, installation and configuration of your own bouncy sink.

read more

How to Generate Realistic Test Traffic Patterns in your SparkPost Account

Behold, a “bouncy sink” that behaves like real-world recipients and a “traffic generator” to easily test traffic patterns and complex sending environments.

read more

Get started and start sending

Try SparkPost and see how easy it is to deliver your app’s email on time and to the inbox.

Try Free

Send this to a friend