From Monitor To Mobile: Optimizing Email Newsletters With CSS

Advertisement

HTML email has a reputation for being a particularly tough design medium. So tough, in fact, that many designers regard coding and testing even the simplest email design to be almost as bad as fixing display quirks in Internet Explorer 6, and only slightly better than a tooth extraction. So, it’s with much courage that I tell you today about using CSS in email newsletters: what works, where it’s going and what you should do next.

After reading this article, you will hopefully come away with a few ideas on how to start coding email designs with improved readability and usability when viewed in Web, mobile and email desktop clients alike. Also included are a variety of resources to get you on the right path with using CSS in email.

Then again, the shaky state of email standards today may convince you that plain-text email is the way to go. The choice is yours.

CSS In HTML Email: The Good, The Bad And The Mobile-Ready

If you’re about to embark on your first HTML email coding job, then you probably come from a Web background and are keen to flex a little CSS3 muscle, get a little JavaScript action happening, drop those shadows…

Not so fast. As any old hat to the email game can tell you, what works on the Web and what works in email are about as far apart as Sydney and Stockholm. For the most part, this is because pretty much every email client has its own way of doing things; while there are perhaps half a dozen browsers to test against when coding a Web page, there are literally dozens of email clients, many of which feature radically different CSS implementations.

But before you give up hope, here’s some advice to get you through the night:

  • A lot of CSS properties (such as font, color and border) work fine across many of the most popular email clients. Once you know which ones they are, you can tailor your designs accordingly.
  • When a CSS property doesn’t work so well, there are often workarounds (such as using cellpadding in tables instead of padding).
  • When workarounds don’t exist, focus on graceful degradation.
  • Your design will never look exactly the same across all email clients, no matter how you use CSS. Once you (and your clients) make peace with this, I guarantee you will sleep better at night.
  • Keep it simple. The less complicated your design and layout, the less likely something will go wrong. Favor table layouts over divs, and make sure your message is readable (which means text, not images).

At this point, you may be saying to yourself, “Well, this all just sounds too hard.” So, perhaps I should remind you how beautiful an HTML email can look, with just a sprinkling of CSS:

ABC Widgets Newsletter

For a more realistic view of what this design will look like in the inbox, here’s the same email in Gmail and Outlook 2007. Both are notoriously tricky email clients to work with:

Gmail

Outlook 2007

See? Ain’t so bad after all. But what’s more exciting is how you can use CSS to adapt an HTML email for optimal display on mobile devices. Here’s the same newsletter as viewed on the iPhone:

Newsletter on the iPhone with mobile CSSImages with mobile CSS

For comparison, let’s look at the same email newsletter without mobile-specific CSS:

Newsletter without mobile cssImages without mobile CSS

The change might seem subtle, but applying a mobile-specific style sheet has improved the readability of the email considerably. It has also allowed us to remove a lot of visual clutter (like the “Widget August 2011 Newsletter” text) that would have taken up valuable real estate on a small screen.

So, we’ve gone from an email layout that requires a lot of pinching and zooming, to one that can be easily read with a linear scrolling motion, using CSS alone. We’ll look at how you can apply similar improvements to your email campaigns in a moment. But first, let’s start with some of the fundamentals of using CSS in your HTML email designs.

The State Of CSS Support In Email Today

When I mentioned that a lot of CSS properties out there work fine in many email clients, I wasn’t trying to be vague. Thankfully, the research into what works and what doesn’t has already been done. You need only skim this guide to CSS support in email clients to see what properties are within and off limits. Or just know that most of your CSS rendering troubles will come from Outlook 2010, Lotus Notes and Gmail, due to their refusal to do anything useful with CSS style sheets.

These issues are nothing new. Indeed, the battle for market share between email clients that play nice with CSS versus those that don’t has been pitched for years now. But progress is being made. Looking at the data from over 3 billion emails sent, we found that mobile email clients have gained ground dramatically with the growth of mobile professionals. In fact, one in five emails are now opened on a mobile device. Here is how desktop, Web and mobile email clients have fared comparatively over the last two years:

Email Client Trends, June 2011
Desktop, Web and mobile email client market share, 2009 to 2011.

Mobile’s ascent is great news for email designers everywhere for one reason: roughly 75% of mobile email is read on an iOS device. iOS devices use the Webkit rendering engine, which means they can display really nice-looking HTML emails.

Our friends at Panic (the creators of such popular Mac titles as Coda and Transmit) were well aware of this when they got started on their email announcements. As purveyors of Mac software, they can pretty much always count on their emails being read in Webkit-powered email clients like Apple Mail and the iPhone. As a result, they’ve been able to pull a lot of CSS3 trickery out of the toolbox, including border-radius and text-shadow:

Panic’s email newsletter

But what really impressed me was their use of CSS3 animation. Here’s the code they used to achieve this effect:

-webkit-animation-name: 'glow';
-webkit-animation-duration: .7s;
-webkit-animation-iteration-count: infinite;
-webkit-animation-direction: alternate;
-webkit-animation-timing-function: ease-in-out;

And you thought HTML email was a boring medium? Well, to temper things a bit, CSS3 still has very limited support beyond a handful of Webkit-powered email clients, so use it with discretion. But with that in mind, let’s look at Panic’s newsletter again, this time on the iPhone. For comparison, here it is both with and without a @media query (which calls the mobile style sheet):

Let’s now look at how you can optimize your email newsletters for small displays as well.

Inside An HTML Email Builder’s Toolkit

Before we go charging in and dropping @media queries by the dozen, let’s make sure we have the tools for the job. We’ll need the following:

  • An email marketing service like MailChimp or CampaignMonitor to send HTML email campaigns (you can’t do this from desktop or Web email clients like Gmail — sorry);
  • Code editing software, such as Coda or Dreamweaver;
  • A mobile device to test on (like an iPhone or Google Nexus);
  • A variety of Web and desktop email accounts to test, either set up individually or automated via a service such as Litmus;
  • An intermediate-level understanding of HTML and CSS;
  • A lot of patience.

In addition, you’ll need a way to move your CSS inline, for the benefit of clients like Gmail, which strip out the head section of HTML email code. Many email marketing apps can do this automatically when you import your campaign, but if yours doesn’t, then you can use a service like Premailer or MailChimp’s Automatic CSS Inliner Tool for the job. Note that Premailer currently strips out @media queries, so you’ll have to paste them back in prior to testing your design.

Now that you’re armed and dangerous, let’s launch into the theory and code behind mobile email design.

Using CSS To Optimize Your Email For Mobile Devices

If you’ve created mobile style sheets for the Web or have read into responsive design, then you probably know a bit about @media queries. If not, then here’s the skinny: they allow you to provide targeted CSS style sheets that are triggered when a device’s capabilities match specific criteria. For example, you could use a media query to specify that a couple of lines of CSS be applied exclusively to devices with a display width of up to 480 pixels, in order to make your website or email easier to read on these screens.

The following is a snippet of code from the earlier newsletter, telling mobile email clients and browsers to scale down the width of the email layout to 300/325 pixels wide, so that it fits comfortably on displays that are no wider than 480 pixels (i.e. the width of an iPhone in landscape mode):

@media only screen and (max-device-width: 480px) {
   …
   table[class=table], td[class=cell] { width: 300px !important; }
   table[class=promotable], td[class=promocell] { width: 325px !important; }
   …
}

Note how we’re using attribute selectors here. This is to prevent Yahoo! Mail Beta from accidentally calling this style sheet.

One thing to note at this point is that, while you can shrink the dimensions of a design (or hide bits, as we’ll do later) using an @media query, the user will still be downloading all of the content. Adding mobile-specific styles shouldn’t be confused with providing a slimmer or faster-loading version of your content. Mobile-specific styles just make the content easier to read.

The great news is that mobile email clients such as iOS Mail and Android’s default mail client follow @media queries to the letter. So, for example, you could pop one into a style sheet in the head of your HTML email code to transform the design into an easily readable, mobile-friendly layout like the one pictured above. You can also do things like shrink the dimensions of images, and use display: none to hide visual elements that don’t work on small screens. We’ll be using the latter CSS property in the tutorial below to make a lot of email content fit into a very small space.

Using Progressive Disclosure To Shrink Content On Mobile Devices

Now that you have the fundamentals of developing mobile-friendly email designs down pat, let’s learn about an advanced mobile email design technique called progressive disclosure. This involves hiding content behind an interactive element, such as a button or link, and then displaying it on click (or tap). In the context of mobile email, the content might be paragraphs of text that require a lot of scrolling — which, you may know from personal experience, is hard to do. Here is an email design with multiple articles:

The problem here is that even if the email design is optimized for mobile, only the first article will be visible without scrolling. So, if you want your readers to know that there are two or more articles, you could apply progressive disclosure. After all, the mobile version of Wikipedia uses it, and a lot of mobile apps use it, so why not apply it to email?

First, here’s a shot of what we’re going to achieve on mobile devices:

Notice how the articles are shown and hidden using a toggle button? To achieve this, let’s walk through some fairly straightforward code. First, there’s the code for the individual articles:

<td>
   <h4><a href="http://yourdomain.com" class="link">First heading</a></strong></h4>
   <a href="#" class="mobilehide">Hide</a> <a href="#" class="mobileshow">Show</a>
   <div class="article">
      <p class="bodytext">
         <img src="kitten.jpg" style="float: left;" >Pellentesque habitant morbi…
      </p>
      <a href="http://yourdomain.com">Read more…</a>
   </div>
</td>

Take note of the classes mobilehide, mobileshow and article. These will be handling most of the action.

Then, in a regular CSS style sheet (i.e. one not enclosed by a @media query), we’ll use display: none to hide our show/hide button in desktop and Web email clients. Here’s the code snippet for that:

a.mobileshow, .mobilehide {
display: none;
color: #fff;
}

Yes, so we’ve had to “white them out” for the benefit of Gmail and Android Gmail, which don’t support display: none. Thankfully, the buttons are unresponsive in those clients.

Finally, onto the mobile-specific CSS in the @media query, which I’m sure you’ve been waiting for. Here, we’ll style the show/hide buttons and handle the swapping of states when the show/hide button is tapped:

@media only screen and (max-device-width: 480px) {
   …
    a[class="mobileshow"], a[class="mobilehide"] {
      display: block !important;
      color: #fff !important;
      background-color: #aaa;
      border-radius: 20px;
      -webkit-border-radius: 20px;
      -moz-border-radius: 20px;
      padding: 0 8px;
      text-decoration: none;
      font-weight: bold;
      font-family: "Helvetica Neue", Helvetica, sans-serif;
      font-size: 11px;
      position: absolute;
      top: 25px;
      right: 10px;
      text-align: center;
      width: 40px;
   }
   div[class="article"] {
      display: none;
   }
   a.mobileshow:hover {
      visibility: hidden;
   }
   .mobileshow:hover + .article {
      display: inline !important;
   }
   …
}

With this added to your HTML email code, you should be able to toggle the display of articles in your email design by tapping the show/hide button, like so:

Despite the imperfections in this implementation of progressive disclosure, we’ve found that this technique works like a charm in iPhone Mail and Android Mail. In mobile clients that don’t play so nice with CSS and @media queries (i.e. Android Gmail, BlackBerry and Windows Mobile 7), the text will display, but the show/hide button conveniently does not. For more detailed information on using progressive disclosure, CampaignMonitor’s article “Optimizing HTML Email for Mobile Using Progressive Disclosure” is well worth a read.

Well, that’s enough information on mobile email design to elevate you to black-belt status. For a more hands-on look at mobile email design, I highly recommend the tutorial, “Make Your HTML Email 5× More Mobile-Friendly.” And read “Mobile Email Design in Practice” to get started downloading a mobile-optimized template.

What’s Next For HTML Email Designers?

So, while CSS-unfriendly desktop clients and Web email clients like Gmail will always be here to rain on our parade, the good news is that the rise of mobile email has meant that we may soon be at liberty to create more Web-like email experiences. It has also meant that optimizing your newsletters for handheld and touch displays has gone from being a “nice thing to have” to a given. This doesn’t just affect email newsletters at the code level, but it also changes the way we display design elements. For example, in the following two mobile designs, which do you think is the more effective call-to-action (CTA) button?

Call to action buttons on a small screen

Or consider the CTA in the following mobile-friendly email. If it’s not visible “above the fold,” as they say, then will it be seen at all? Or worse, will recipients end up accidentally tapping the toolbar instead?

CTA is obscured by the toolbar

If designers aren’t asking these questions, they sure will be soon. You need only visit Style Campaign’s blog (which provided the examples above) to grasp the importance of solid mobile design.

Here are a few other important things to consider when designing adaptive layouts:

  • Single-column layouts that are no wider than 500 to 600 pixels work best on mobile devices. They’re easier to read, and if they fall apart, they’ll do so more gracefully.
  • Links and buttons should have a minimum target area of 44 × 44 pixels, as per Apple guidelines. Nothing sucks more than clouds of tiny links on touchscreen devices.
  • The minimum font size displayed on iPhones is 13 pixels. Keep this in mind when styling text, because anything smaller will be upscaled and could break your layout. Alternatively, you could override this behavior in your style sheet.
  • More than ever, keep your message concise, and place all important design elements in the upper portion of the email, if possible. Scrolling for miles is much harder on a touchscreen than with a mouse.

Now it’s your turn to design wicked HTML email newsletters that, with a dash of CSS, look just as effective on the small screen as they do in your Web browser or desktop inbox. I have no doubt that your readers will appreciate the effort.

Resources To Help You Make The Most Of CSS In Email

With funky CSS support and coding practices from circa 1994, designing HTML emails might seem like rocket science. Thankfully, quite a bit of solid documentation exists on effective HTML email design, so below is my recommended reading list if you want to take your newsletters to the next level.

Getting Started With HTML Email

HTML and CSS in Email Clients

Mobile Email Design

Email Design Inspiration and Templates

(al)

↑ Back to top

  1. 1

    Great article Ros. Love where html email is headed!

    0
  2. 3

    Good article. But as long as Microsoft decide to use not IE-Rendering for their Outlook, HTML-Mails are made in HTML4 :-(

    0
    • 4

      The best way to get mail to mobile via sms is to use 3rd party service called weekwill.com. it allows you to receive email notifications on mobile through SMS within seconds. I tried it and it works perfect for me.

      0
  3. 5

    Definitely up there with fixing design quirks in IE6! HTML Email’s are something I (thankfully) don’t have to do very often, but when I do – maaan it’s a pain.

    Many thanks for the article. I’ll have to put the kettle on and sit down and read this in depth. Several times.

    0
  4. 6

    Thank you, Ros. Just yesterday we had to struggle again with HTML eMail newsletter rendering in older Outlook versions. About 40 percent of our client’s recipients use Outlook as their mail application. This is the reality…

    0
    • 7

      Supporting Outlook, Gmail and less CSS-friendly email clients will be the norm for a while yet, sadly. It’s still worthwhile to add nice optimizations, but you have to be careful to ensure they degrade nicely.

      0
  5. 8

    A very very solid article Ros. Explains a lot of stuff for inexperienced e-mail designers or HTML designers who have do design e-mails like me. Just a question since you are experienced, would you recommend E-mail on Acid or Litmus for e-mail acid tests ?

    0
    • 9

      Both testing tools have their strengths. While Litmus has a very elegant interface and is very straightforward to use, Email on Acid is far more verbose about why rendering issues may be occurring in individual email clients and is in my opinion, better suited to more technical users. I’d give both a go and decide from there :)

      0
      • 10

        Unless this has changed recently Email on Acid will render your HTML by the rules it’s determined the email client uses.

        In other words, it doesn’t actually send your email to a (for example) gmail account.

        It parses your code according to it’s interpretation of gmails rendering engine and provides you with that.

        When Litmus (as well as others) test you email they’ll literally deliver to a gmail account and send you a screenshot of the results.

        I’ll usually use Email on Acid or Get Fractel for error detection and will then run the email through Litmus as a final test.

        EoA also produces test results much faster then Litmus which is helpful when troubleshooting.

        I find both methods useful, but not for the same uses.

        0
  6. 11

    As someone who relies pretty heavily on their mobile device for checking emails, there’s been too many times I see newsletters that you have to resize for “proper” viewing. This alone makes keeping my interest in all of the email content somewhat of a struggle. But the future is looking good! With the incredible increase of smartphone users viewing emails on their mobile devices, I hope to see big changes sooner than later.

    0
  7. 12

    Nice one Ros, been waiting for you to pull this all together in one place. It’s worth mentioning that testing media queries couldn’t be easier with a modern browser. If you use:

    @media only screen and (max-width: 480px) {
    ...
    }

    Instead of ‘max-device-width‘, then you can just resize your browser to see the changes take effect (don’t replace proper testing on the device itself though). Is there a reason you use a media query that targets devices specifically, rather than just small screens?

    I put together an example using a a Starbucks email a while ago, which shows how you can hide images completely and make use of background images, which is something I haven’t seen used in the wild.

    This test page is helpful in showing how to prevent mobiles downloading background images meant for the desktop. Is it definitely the case that if you set the parent object to display:none then the images contained within are downloaded? And if so, does anyone have any smart ideas to prevent this that don’t rely on being clever server-side?

    0
    • 13

      Hi Ed, thank you for your kind words :) We’ve used max-device-width with the assumption that both senders and subscribers want the mobile version of an email to display on mobile devices only. For example, it may not be appropriate to have this version show up in desktop or webmail clients, because their preview pane has been shrunk down. This is a matter of taste, though.

      Secondly, max-width and max-device-width have different meanings on mobile devices. QuirksMode has a good discussion on this (scroll down to the ‘Media Queries’ section).

      The Starbucks example you have there is excellent and I can see why using max-width could be a sensible alternative for folks who want to optimize their designs for small displays in general. I’d be keen to test this approach (with the above in mind) and potentially cover the pros/cons in a later resource. With kudos to you, of course :)

      Yes, using display:none; still results in background images being downloaded, even if they aren’t displayed. I don’t know of a way to prevent this server-side (especially seeing as we can’t add any scripting to email), but I’d be keen to hear comments from others.

      0
      • 14

        That makes a lot of sense, thanks – I’d be lost without Quirksmode, but there’s only so much I can read about CSS vs actual pixels before my brain turns to mush.

        I had in mind this example at Style Campaign that uses a dynamic image server to look at the UA string and serve different images based on that. That article is helpful in laying out some of the down-sides of using media queries for the task, but for the majority of people (especially on smaller campaigns) I don’t think it’s a tenable solution. Plus I love the simplicity of being able to govern all this entirely in the HTML/CSS.

        0
  8. 15

    I really enjoy designing email campaigns, just like tight budget projects, the limitations require everyone to keep things simple and effective.

    0
  9. 16

    A lot of designers try to bypass the css issues in emails by making them image heavy – it is really important to remember what your email looks like if the images are not downloaded! In the top ‘abc widgets’ example, in a small window, the email would simply look like a blank page until the user scrolled down to see the text.

    0
    • 17

      Agree, if anything the example in this article shows the benefit of purposefully using text early on in email designs, over featuring a large, flashy header image (as is common). Thank you for pointing this out :)

      0
  10. 18

    Great stuff!

    Let’s have more like this. I just finished coding an email that took 14 hours and nested tables 6 layers deep. I need more of these articles!

    0
  11. 19

    I love you Smashing Team!
    Always useful articles :)

    0
  12. 20

    Aside from the obvious punt for Campaign Monitor… I use it and can recommend it as the very best service on the web. We’ve tried a whole bunch of HTML email / Email Marketing services and Campaign Monitor are far ahead of everyone else.

    I run a web dev & design company – Black Square Web Solutions – in South Africa (which means my support guy at Campaign Monitor is in Norway…). In SA we have ridiculously slow and expensive bandwidth, a very inexperienced market which is only just starting to understand how email marketing works, and on top of that we have a very small mobile internet market compared to the USA. Nonetheless we are finding more and more people coming to us wanting content to work on mobile. Campaign Monitor’s latest update has made this all a lot more possible and easy to work with.

    Good work.

    0
  13. 21

    good work Ros – we’ve been using this for a while from the stuff on the CM blog. Still need to shoot over some examples!

    Guys – to the point about Outlook – you’re right, it’s always going to be an issue, and the reality is even if outlook added decent html support tomorrow it’d still take years to become adopted worldwide. However the stats for mobile email opens are rising sharply – which is starting to erode Outlook’s share.

    At the most basic level using this technique, you can use media queries to have two complete sets of HTML – one for desktop and one for mobile. I know that’s incredibly dirty and has duplication of content issues, but it’s a start.

    btw – as you’ve probably guessed I work with html emails every day, give me a shout on Twitter if the code’s doing your head in and I’ll try to help! – http://twitter.com/#!/iamelliot

    0
    • 22

      Love your work, Elliot – I’m keen to see more mobile email examples in the wild (especially by you)!

      A +1 for following @iamelliot on Twitter – it’s great to see experienced email marketers out there sharing their knowledge with the wider design community.

      0
  14. 23

    Thanks Ros Hodgekiss,

    I love working with Campaign Monitor, I’ve working with Mailchimp, Copernica (and used to work with E-mark (Dutch).

    The future for e-mailmarketing looks hopefull again. Outlook 2010 is terrible for e-mailing HTML but more and more people check there e-mail on a mobile device. And I must say, the iPhone seems to handle e-mailing HTML quite well.

    Cheers,
    Lucas

    0
  15. 24

    Excellent article as always!!!!!
    May I suggest an article regards Formating & Optimizing RSS and RSS by email.

    I love you guys,

    Betty

    0
  16. 25

    I’d also suggest using Email on Acid to test your HTML emails. They offer code-analysis which is very helpful in troubleshooting why an email is not displaying correctly.

    Great Article! I am definitely going to use some of the suggested techniques.

    0
  17. 26

    Love the article!

    I wanted to point out that I’ve used attribute selectors for the Yahoo issue and found that I still got the mobile version. But then, I used “div:not” ALONG with the regular CSS and that seemed to work!

    0
  18. 27

    It looks so good. it makes me want to give them my email and subscribe to it.

    0
  19. 28

    Just when i needed this the most :) tx

    0
  20. 29

    hahahahahaha what. A float? Just hope your clients don’t open that on, say, outlook?

    I agree with stuff not looking the same but images not floating just look retarded. Table that shiz already. It is still 1998.

    0
    • 30

      I believe float’s work in Outlook (or at least won’t mess it up) though you’ll need to use the img align attribute as well.

      Something like:

      However adding margins or padding into that img tag will cause it to screw up.

      It’s not always possible to hardcode in image placement into an email that’s going to be used as a template as you can’t always be certain the end user will want an image included.

      0
      • 31

        The code got stripped.

        It was an image tag with an a l i g n = ” left ” and a s t y l e=” float: left; “

        0
  21. 32

    Ros says that that “roughly 75% of mobile email is read on an iOS device”, quoting her employer, but ignores their own Fine Print:
    “The email client a person is using can only be detected if images are displayed. This can give an inflated weighting to email clients that display images by default, such as Outlook 2000 and the iPhone. It will also provide a lesser weighting to those that block images by default such as Gmail and Outlook 2007. Those email clients that aren’t capable of displaying images, such as older Blackberry models and other mobile devices cannot be included in this study.”

    So Campaign Monitor’s stats ONLY include insecure email clients that DON’T block web beacons! (Anything old, or Apple). Some kudos to them for admitting that they can’t collect accurate data (although in such fine print that their own employee missed it).

    But the article’s premise (about The State Of CSS Support In Email Today) is flawed.

    0
    • 33

      Hi Rob, thank you for pointing this out. I agree that the mobile usage numbers here may not be reflective of all mobile email clients due to the limitations we have, however they are still useful for determining which mobile email clients are most likely to be used by email subscribers (and importantly, are capable of displaying an HTML email with some integrity). Even if true iOS email client market share is considerably less than the ‘rough’ 75% today, their rapid and ongoing growth should be of interest to email designers.

      We also successfully collect email stats internally for Android, Windows Mobile 7 and Palm Pre devices, which all happily display HTML email (and images). Stay tuned, as we’ll be certain to provide email client growth statistics for these clients at a later date ;)

      Happy to further discuss the collection of email client statistics with you, so feel free to drop me a line if you would like further info on the above.

      0
    • 34

      Pete Austin @marketingxd

      September 12, 2011 3:08 am

      @Rob, exactly right. The effect you mention inflates the counts for the iPhone and (because that is so popular) hugely inflates the proportion of email read on mobile devices.

      I attempted my own corrected estimates in Summer 2011. Mobile was actually about 5% (not 20%) of the total – made up about 40% from each of Android and iPhone, 10% iPad, and 10% everything else. See this link for more details:

      http://blog.marketingxd.com/post/6856085970/mobile-is-5-of-email-not-20

      0
  22. 35

    Hi,

    I have doubt that as we know in emailer only inline css style will work.
    Is this possible to call css file from externally…

    0
    • 36

      It’s not reliable, I’m sorry to say. A lot of email clients don’t support the LINK tag for calling external stylesheets – take a look at this guide for an overview.

      I’d definitely recommend using an inliner like Premailer instead.

      0
  23. 37

    As per usual Smashing is a major resource to help me out! Thanks for the great info!

    0
  24. 38

    There have been many that have highlighted the lack of functionality in Outlook. And there are plenty of people (myself included) that are keen to see email clients catch up with modern browsers.
    I think the main thing that is overlooked is MS Outlook is still the most used email client & will be for some time. MS decision to ignore requests (www.fixoutlook.org) of our industry means this issue will persist for some time.

    They have no intention of changing their rendering engine from MS Word… sigh!

    0
    • 39

      Maddening as Outlook’s terrible CSS support is, I think the important thing to take away from this article is that, in some respects, it doesn’t matter. If you’re clever with your initial coding, the desktop view just won’t be affected (or there will be minimal impact), and you can make the mobile version sing.

      0
  25. 40

    Alright boys, just so you know, your getting MAD errors on this page…. My count reached 48, and what are you doing with local storage?…. is this horrible banner code or something? the errors are counting up as a I scroll up and down the page, and pertain to
    ——-
    if(typeof CE2==”undefined”){CE2={}}CE2…pires=”+a}};CE2.onDOMReady(CE2.main)};
    ——
    that code.

    Thanks for the great articles, keep it up guys, you are legends.

    0
  26. 41

    Christian Krammer

    August 25, 2011 5:35 am

    I am a big advocate of CSS3 and the like, but I really can so no point to use CSS3 respectively too much CSS at all, in newsletters now and in the near future. Because if even the most basic properties/techniques are not supported in two of the main clients, Notes and Outlook 2007, than the extra work really is hard to justify.

    But it nevertheless is nice too see some approaches how to use our beloved CSS3 in newsletters. So thanks for the effort. :)

    0
    • 42

      Using CSS3 is fine, as long as it degrades gracefully in email clients which don’t support these properties. I’ve seen some email newsletters which are gorgeous in Apple Mail, but are still very much readable in Notes – for recipients using the former email client, the effort may well be worth it :)

      0
  27. 43

    Thanks for another great article, Smashing. However, I am still lost about how the @media query is rendered with comparing email marketing service providers. I tested @media in Campaign Monitor, Mail Chimp & Constant Contact. ( Of course as a designer I prefer to use CM but many of my clients cannot be convinced to move over from MC or CC.) Looking at the same email on my iPhone from all 3 providers – only Campaign Monitor wins the award for showing correctly. The email is squeezed/shruken in the other 2. I have scoured the internet for a post or article that discusses mobile emails tests across email markeing services and have come up blank. Has anyone tested this? Does MC and CC strip the @media code? I can see it when I view in web browser but am unable to view message headers on my iPhone to see what is going on. (any app for that?)

    Would love to hear any ideas about how MailChimp and Constant Contant handle mobile emails differently than Campaign Monitor.

    0
    • 44

      Anne Marie, I’ve also come up blank on @media rendering in MailChimp… till I found your comment here. MailChimp is stripping out my @media queries in both the template edit/code view and if I import into a campaign. MailChimp’s knowledgebase articles make no mention of @media queries, which leads me to believe they do not support this yet, otherwise they’d be touting this feature.

      0
    • 46

      I contacted MailChimp support, and they confirmed @media queries are incompatible with their service. I posted it to the MailChimp wishlist here…
      http://jungle.mailchimp.com/forum/topics/enable-media-query-compatibility-so-that-designers-can-target

      0
      • 47

        For me mailchimp is working. I added style in the header and its working. The rest of the css is inline.

        0
        • 48

          @Bapin, but you didn’t use @media with MailChimp, correct? If so, and you got it to work, would love to see how you did it. But as I understand it, @media in MailChimp absolutely does not work. Their processes strip out the @media line, so that CSS is applied to all emails regardless of client.

          0
  28. 49

    Hi – in all of the “best practices” webinars I’ve been to the standard recommendation seems to have been DON”T USE CSS but rather simple hand-coded HTML because of rendering issues. Is this no longer a problem for email clients (non-mobile)?

    0
    • 50

      Hi Mike, in cases when you want an HTML email design to look exactly the same across all email clients, then I’d say don’t use CSS. But if you’re happy to accept that there will be rendering differences from one email client to the next, then your designs will most certainly benefit from using CSS to improve readability and well, just look nice.

      Most email clients these days will have at least basic support for CSS properties. Of course, there will always be problems with clients like Outlook ’07 (which takes a rather arbitrary approach to CSS support), but with a bit of clever coding, you can still make HTML email newsletters look very presentable in these clients and moreso in others.

      For an idea of what designers like yourself are creating and sending with a little HTML and CSS, I highly recommend you sample some of the designs in our gallery.

      0
  29. 51

    Thanks for writing. I have an article @ http://blog.designingstudios.com/psd-to-newsletter.html

    0
  30. 52

    I think Emailwear (http://www.emailwear.net) deserves to be listed in the “Email Design Inspiration and Templates” list.

    0
  31. 53

    All the things mentioned in this article don’t seem to work unless you use the viewport meta tag to specify the initial scale. Am I the only one experiencing this?

    0
  32. 54

    I stumbled upon this article and thank you very much. It, combined with some of my other more recent research has answered a TON of my mobile only questions.

    0
  33. 55

    Useful article although I disagree with this idea that ‘scrolling on mobile is much harder’… since when was flicking your finger in an downwards direction hard? I personally find scrolling on mobile absolutely fine. Infact, the smooth scrolling physics which the iPhone first perfected was the key turning point in my mobile web usage.

    I’d like to know what anyone else thinks about scrolling on mobile… do you find it hard? If so why?

    0
  34. 56

    Liga Polskich Rodzin

    October 5, 2012 6:50 pm

    You’re in point of fact a good webmaster. The web site loading velocity is incredible. It seems that you are doing any distinctive trick. Also, The contents are masterpiece. you’ve performed a fantastic activity in this subject!

    0
  35. 57

    Great article !. Love where HTML email coding is headed!
    I use htmlforemail.com for all my developer needs

    0
  36. 58

    Good article.
    Correct me if I am wrong. You mentioned using @media query in html emails. Bit most email clients wont support them like gmail app for iphone and ipad and other android email clients. Read on this site
    http://www.emailonacid.com/blog/details/C13/media_queries_in_html_emails

    I came to this article to find a solution so that users viewing emails in their mobiles dont have to zoon in.

    I was thinking of designing a email with 100% width table and just one td (column)

    0
  37. 59

    GMail’s lack of support for display:none; can be overcome by using width:0;height:0;max-height:0;overflow:hidden;

    Works for both images and chunks of text.

    Just reverse the inline style with your Media Query for mobile.
    Be sure to tag !important on all your mobile styles or they won’t override the inline ones.

    0
  38. 60

    The “show/hide” mechanic is nice, but you should avoid having links in the shown content… Cant click them like this.. Someone else having this problem? Any solution?

    0
  39. 61

    My favorite mobile mail application was actually recommended to me by a co-worker. It’s called Ark Mail http://www.ark.com It really helps me keep both my personal and business email accounts organized, while still having them in the same place.

    0
  40. 62

    Hi,
    I tried placing the media queries and checked in Chrome with Gmail account and did find any changes across mobiles. Gmail has just removed all the style codes… :(

    Help needed…

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top