MailChimp and Media Queries

July 2012 Update: I don’t do this nearly often enough, but following some comments, I’ve made a few updates to this post to alleviate confusion. Most importantly, I’ve added a new version of the template provided at the end; it looks virtually the same, but is built with more stable and modern code that reflects our current techniques. I’ve also updated the screenshots in the post itself, adding "!important" declarations that were missing (which made it unclear as to whether they needed to be there or not – they are needed). I’ve left the majority of the content as-is, since it still reflects a sound methodology.

It’s no secret that mobile readership of email is skyrocketing. In May of 2011, Return Path released a study in which showed an 81% increase in mobile viewership over the prior 6-month period. Then, in September, Litmus released its own study which bore out many of the same conclusions.

Litmus’ number was a little higher: 150% over the previous 6 months. I don’t know what the margin of error is in either study, but even being conservative and splitting the difference between the two numbers nets you a healthy increase. Either way, these numbers show that people are overwhelmingly choosing to view email on their Androids, iPhones, and iPads, and that means finding a way to optimize email for smaller screens.

All of this is a long-winded way of saying that media queries are a way to optimize email for mobile devices, and MailChimp v6.8 now supports them in the normal campaign workflow.

Now, chances are that if you do code your own templates, you already know what media queries are, you stopped reading at "MailChimp v6.8 now supports them in the normal campaign workflow," and have moved on to implementing media queries into your templates. For the rest, what follows is an overview of what a media query looks like, how to implement it into your code, and even how to set it up so that you can adjust the media query style rules within MailChimp’s campaign editor.

We’re starting with a simple, blank template…

A lightly-modified version of the "basic" template from MailChimp’s "basic layouts" library.

…and styling it with basic CSS:

The same template, after some styling and content.

If you’ve never worked with one, the idea behind a media query is basic: it’s pretty much a CSS stylesheet within a CSS stylesheet; a collection of CSS rulesets that are read and rendered when the trigger for the query is hit. Here’s what the opening lines of a media query look like:

The opening of the media query.

The media query contains two important components: "screen" and "max-device-width." The "screen" component is the media type and the "only" is, as the W3C so eloquently puts it a keyword that’s "…used to hide style sheets from older user agents." The second component, within parentheses, is the actual query; the media feature (max-device-width), along with the trigger value (480px). In short, this media query says "These styles should only be used for screens, and only when the screen’s horizontal width is 480px or less."

The W3C Article (or W3C Candidate Recommendation Document, if you’re feeling fancy) linked above lists out the other media features you can trigger on, but for the purposes of this email template, we’re only concerned with device-width.

While you can do all sorts of neat stuff with email-valid CSS, there are three things I’ll focus on: email width, header image width, and font sizes.

Since most emails are wider than 480px (the landscape width of the average device), most emails will trigger horizontal scrolling. For the sake of this post, we’ll assume we don’t want that. Thus, the two basic ways to change the width are by either setting a hard value like 300px for your email’s tables, or to set a hard upper limit with max-width, then set table widths to 100%. That’s what I’ve done here, targeting each table that gets its width set:

This method lets the email fill the viewport up to a limit of 600px.

Next, since the header image in this email is also 600px wide, we should scale it down in line with the email’s total width. The same method used above can be applied to the image (The vendor-specific style rule "-ms-interpolation-mode:bicubic;" is there to account for IE7’s inability to scale images down without making them look horrid):

The header image will fill adjust with the template, to the same limit of 600px.

Finally, we should increase readability on small screens, so bumping up the font sizes automatically is important. A good rule of thumb is a font size of at least 16px for your copy and 20px for your main headings. That might strike you as big, especially if you send tons and tons of content (which you shouldn’t). Our friends at Smashing Magazine posted an article that argues otherwise. The article isn’t specifically concerned with email, but it’s relevant and right. For this email, I’ve bumped the font size up to 18px:

An 18px font size allows for comfortable reading.

After adjusting font sizes in the preheader, body, and footer, and adjusting heading sizes, this is what the full media query looks like:

The full media query stylesheet for this email.

I’ve left one detail for last. If you look at the media query styles, you’ll notice I targeted my tables and table cells using an attribute selector ( table[id="templateContainer"]{…} ) instead of using the traditional CSS route ( table #templateContainer{…} ):

Not bad, for such a small amount of work. You can even save yourself a bit more time by marking the CSS rules in your media query with MailChimp’s template language editable tags. This will allow you to edit the values of your CSS properties when inside the app’s campaign editor. Simply follow the same pattern already established by the template language:

Avoid digging into your code every time by making query styles editable in the app.

You can download and play around with the template I used right here. That’s all I’ve got. Time to dance.

Tagged

How well do your styles work across different mail reader platforms? Outlook Express, Outlook, Hotmail, iPhone, etc… I’m guessing some of them won’t render media queries properly. Can you post screenshots of the different desktop & web based clients displaying the same email?

This (at a glance) doesn’t seem to apply the 320 and up methodology that starts with the smallest screen size, and enhances displayed content as the screen size increases. If you don’t follow the 320 and up methodology, you end up making mobile users download much larger graphics than they want for their tiny screen size. This means you use more of their data plan which costs your recipient money. This may prove difficult to achieve in mobile email design due to not having JavaScript available in most email clients.

The point is that the most mail clients will ignore the styles in any media queries and show the desktop version (which is fine, we’re targeting only small screen sizes). The alternative is to use a fully flexible, 100% width layout which always fills the available space: fine in some instances, but not always desirable.

Though the ideal would be a mobile-first approach (to keep the overhead for such devices as small as possible), this is a pipe dream for now. If you take pains to ensure your initial markup is as clean as possible and your images are optimised, then you are doing best by all your recipients. The few lines of code for your media queries (that’s really all it takes) are a negligible additional download.

As far as your second point goes, Brian, it got me thinking, and I’m now doing a little write-up on the actual monetary cost of sending these emails without the mobile-first approach. I’ll have it up soon.

Hmmm, this has me thinking about using double-res banner background images in emails for the iPhone and other hi-res screen devices. But I’m a bit concerned about whether or not they’ll get downloaded to email clients that don’t need them. I’m guessing it will be the same as a website – if you put them in a media query for double-res devices they will be ignored by all others, right?

The post doesn’t mention the importance of the !important declaration if you are also inlining your CSS for email clients that strip the section out. If you don’t add !important to all your media query CSS rules, the inline CSS takes precedence and your media queries are useless.

I guess its pretty clear to everyone, but I think it’s worth correcting.On the paragraph that says:
“I’ve left one detail for last. If you look at the media query styles, you’ll notice I targeted my tables and table cells using an attribute selector ( table[id=”templateContainer”]{…} ) instead of using the traditional CSS route ( table.templateContainer{…} ):”

I’d suggest changing “table.templateContainer” to “table#templateContainer” (as in the sentence before it’s referenced as an “id”, not a class).

As simply as can be said, we copied out the sample HTML and @media styling (“You can download and play around with the template…”) and created an HTML email that we’ve been testing out with various mobile phones, Android and Apple, with very little success when it comes to resizing or restricting our 600px header image.

Has anyone actually been successful using the code that’s been shared here?

There’s another method you can try. If your header image is 600px, set that size with the img element’s width attribute. Then, instead of using max-width:600px; and width:100%; in the query CSS, you can simply set the width to a fixed size (300px, for example). It’s not as flexible, but it’s more consistent.

Hrm, it looks like video tags aren’t currently being stripped from emails by our system. We did some testing on our end just to make sure and the video tags were delivered as expected. Some email clients are still a bit shaky with video tag support so that could be our culprit. If you are seeing something like code being stripped from the campaigns, let our support team know when and where the changes occurred. They can dig in and check things out. Support can be reached here for email or chats.

I’ve coded several mobile emails. Mostly the one column approach where I make all tables 300px. But, I tested last night for the first time with MailChimp. The footer that MailChimp adds in there is set to 600 width and is two columns side by side (The send info on the left and the grey mailchimp logo to the right of it).

This causes problems for the rest of the email. I tried scrunching the footer table down with a targeted media query but was unable to get it working. I don’t know maybe there’s a way to do it but it would be nice if that footer was set to have no width so it doesn’t affect the width of the mobile version.

Maybe you guys can look into it and create a new footer with no specified width. Campaign monitor just has a white background footer with no width. Something like that.

I must be missing something here. Whether I view the template from the link provided or test my own version, the email displays identically at narrow browser widths. No font, table or image resizing in Chrome, Safari, Firefox….

Maybe I’m missing something but running into same issue as Dave. Looks great in MailChimp but no resizing on a mobile (YahooMail on Android). Also tried using code concepts in another Email Generator (Responsys… had to for client) and doesn’t work either.

Thanks for this. I tried using the Campaign Monitor guide ‘Designing Responsive Email’ however using their code and resizing tables and images to 320px I could never get the email to fill the entire viewport. However with this code my emails now fill the entire viewport nicely and with the additional code to bump font sizes up it’s very mobile friendly. I took an existing email which had to been designed and tested to work across the major email clients Gmail, Yahoo, Hotmail and Outlook and then added in the media query codes. With a bit of tweaking the original design and also hiding elements using the media queries this now works great.

Hi Alexis, You’re not seeing this work because unfortunately, Gmail doesn’t currently support media queries. I do however have a short article from another site that breaks down support for media queries in mobile email clients that might be of interest to you. http://eepurl.com/sNxBb

tip: if you want the basic template to work in gmail, you need to move all the styles out of the style tags and put them inline i.e. put a style attribute on all elements that need it…. so much for mailchimp having well-tested templates :-)

Hi Paul, The styles aren’t initially inlined as the system does that on the fly before sending. It’s worth noting however, that the styles related to media queries aren’t inlined as they’ll act as overrides only when email clients support media queries. Just for reference, here’s a short article showing some of the email clients that work and don’t work with media queries: http://eepurl.com/ukCDn

So if the media queries aren’t supported by the email browser, will they display the inline styles? Does it make sense to set up media queries and inline styles to cover all bases, or will the inline styles simply override in either case?

If the client doesn’t support media queries, it’ll render the normal CSS. Also, you’ll want to inline the normal CSS and while you won’t inline the media query CSS you’ll want to declare every rule in them as !important so they’ll override the normal CSS when media queries are supported.

Hi David, Unfortunately, Gmail doesn’t support media queries at this time. You can read up on email clients that do support media queries and to what extent in the following article: http://eepurl.com/ukCDn

Hi Robert, Gmail is not yet supporting media queries but if you head over to our email template reference and choose email blueprints You’ll want to take a closer look at Modular Template Patterns. It won’t actually be responsive, but it’ll work a bit closer to what you might hope for in a responsive email and it’ll be a good starting point via our resident template expert Fabio.

Hi,
I’m having some issues getting media queries and the Mailchimp automatic CSS inliner to work together – I have to use to CSS inliner to get emails to display any not-already-inlined CSS properly in Gmail and similar clients, but when I do, it puts all of my media-query CSS inline as well, regardless of the platform that the email is being displayed on. Is there any way around this? Would putting all of the CSS *except* the media query/responsive stuff inline work, so that I wouldn’t need to use the automatic CSS inliner? Thanks!