Why Mobile Emails MatterWhile our mobile website is becoming a larger and larger portion of our traffic, we still see more users on our desktop website. So when we pulled data around our emails (and we love data), we were surprised to learn that most of the emails we send are actually opened on mobile devices.
Just as our mobile site is designed and built to be a great experience on the phone, our emails needed the same special thought and treatment. It sucks to open an email on your phone with tiny text, or images that stretch off the page, or links that are too tiny to click on a touchscreen.
We set out to ensure our emails, whether opened on a desktop client or a mobile phone, were as delightful as the rest of our site. Along the way, we found many guides and blog posts on the Internet, but nothing that laid out the whole process. We also ran into several pitfalls during development that we had to work around, so we've gathered them here in hopes of saving you the pain of having to discover them yourself!
A note about media queriesThere are already plenty of posts on the web about using media queries to build responsive emails. The basics are that you can and should use media queries to target your CSS to certain device attributes, like screen width and retina displays. For this post, our focus will be on information that was hard to find or we didn't come across at all. But if you're not familiar at all with media queries or mobile-friendly email design, reading these articles first will make this blog post much more useful to you.
Step 1: Desktop or mobile?While media queries make mobile-optimizing emails a whole lot easier, keep in mind that many desktop and webmail clients do not support them. They will just be ignored, so you need to choose your defaults wisely. We decided our default experience would be designed for desktop since the vast majority of our mobile users are on iOS and that supports media queries and CSS3.
Step 2: Split your CSS into two filesChances are good that you will be supporting GMail (you can skip this step if you're not), so you will need to split your CSS into two files: inline.css and external.css. Gmail strips all <style> nodes from your document, so you will need to use an inlining tool to move all your CSS styles into the style attribute of each node. Using an inlining tool will simplify your workflow, because you can develop the email as though all clients support style nodes and have it transparently transition those styles to inline style attributes. However, be aware that like any inline style, it does not support pseudo-class selectors like :hover, :after, etc.
For other clients, you can include your external.css in a <style> node in the <head> of your document. However, because your inline.css styles were moved to inline styles, you'll have to add an !important to every rule in external.css to overcome the specificity of the inline styles.
Step 3: Reset your CSSYou should use a standard reset CSS in your inline.css, but most reset rules do not work exactly the same when inlined. Styles like font-size when inlined do not follow the same inheritance chain, so move any default-inherited styles like font-size to a more specific selector like #body.
Step 4: Wrap your email content in tablesFor consistency, you should wrap all of your email's content with a table. Rather than displaying your content in an iframe, many clients will add a prefix to all of your CSS selectors and insert the HTML of your document's body into their page's content. This means that you cannot set any styles on the body tag. We wrapped our document with a table#body and specified a background-color to have our content visually different from the client's interface. This table is also where you can set default font-size / line-height and have it inherit properly across all clients.
Step 5: Use tables for layoutMost of the styles used to layout web experiences (float, position, display: table/inline-block, etc.), just do not work or are not supported in all clients. Unfortunately, in the age of HTML5, you'll still have to use tables for consistent layout in emails. To reset any table rendering differences between clients, always set the following attributes on table nodes:
- table: cellspacing, cellpadding, border
- table: table-layout: fixed (in CSS + inlined in style)
- table and td: align
Step 6: Test, test and test some moreTesting across multiple devices and clients can quickly get tiresome, especially since we love to do quick iterations of design and development. Fortunately, services like emailonacid allow you to send one email and see it rendered on multiple experiences. It was invaluable especially for clients we don't commonly use around the office.
We also built our own test environment so we could have one place to see all of our emails and their variations. With one click, you can see an approximation of what the email will look like on a desktop, phone, or tablet client.
ResultsAnd that's it! After you get one mobile-friendly email under your belt, the rest become much easier. After we switched to our new mobile emails, we saw increases in click-through rates and now we have a full arsenal of tools to make beautiful emails like this one:
Tips & TricksSome final do's and don'ts that can make a huge difference in the final rendering:
Specify a doctypeIf you don't, it can trigger strange quirks modes in many clients. For the most part, the actual doctype you provide will be ignored--it just needs to be specified.
Don't comment your CSSWe are huge fans of well-comment code (including CSS), but we found that including CSS comments could trigger spam filters to treat our emails as suspicious.
Set width on <img> tags, but not heightGMail does not allow you change height in CSS, but if only width is set, height will be calculated based on the aspect ratio of the original image and it will be sized correctly.
Avoid these CSS attributes
- margin: many clients do not support margin of any kind, but especially NO negative margin
- display: many clients do not support any display type but the default, use a default block (<p>) or inline (<span>) element where necessary
- float: many clients do not support float as you would expect, use tables to do your layout
- box-sizing: because you’re using tables anyway, this isn't as useful as you’d expect anyway, probably won’t miss it
- background-image: this does work in many clients, but do not require it to exist for the email to be usable
- position: is not supported at all in most clients, will just throw it away or ignore it
- list-style-type: ignored by some clients, so only use if it falling back to the default for that element is okay
- Supported CSS across email clients
- Supported CSS in Outlook
- Responsive email design
- GMail-specific tips
- Yahoo-specific media query fix
- CSS inlining tool
- HTML email boilerplate