Coding for Responsive Design Part 2: Adapt or Die
By using these Responsive Design strategies, emails can come to life across a variety of devices and contexts.
By using these Responsive Design strategies, emails can come to life across a variety of devices and contexts.
In part one of my Responsive Design Guide, we discussed the importance of adapting email to an increasing variety or devices and contexts and covered the priming of our email canvas.
With that framework in place we can layer on the techniques that will make your emails come to life with Responsive Design.
Media Query Support
Responsive Design relies on media queries in the < style> section of your email. The most common method is to base your design on a desktop format and then use the @media query to serve different layouts or styles when a smaller screen size is detected. The biggest constraint with Responsive Design is that media queries are only supported by newer mobile operating systems. Gmail is the biggest offender — Google does not support media queries in any of their apps or the Gmail Web client.
Supported
Not Supported
Width-Based Rules
Media queries will look for the width of your device or window. On a desktop, device width will change when you resize the window you’re viewing the email on. On a smartphone, it will change when you change the orientation of the device.
The example below uses a max width of 320 pixels, applying styling to any device equal to or less than 320 pixels. This includes iPhones and many smartphones (in portrait view).
< style>
@media only screen (max-width
320px)
{
*/ Styling for smartphone */
}
< /style>
Min-width is used for the opposite purpose, setting a minimum screen size. This example applies styling to desktop or tablets greater than 680 pixels wide:
@media only screen (min-width 680px) {}
Unless you only have a single rule, you should always combine both min-width and max-width in your rules. This ensures that none of your rules overlap one another.
@media only screen (max-width: 320px)
{}
@media only screen (min-width: 321px)
and (max-width: 649px) {}
Adding Styling to Elements
Once we’ve setup our layout with relative widths (see part one for a refresher) you’ll be able to make your entire template adapt fluidly with just a few steps. The easiest technique is to change the values in your styling based on device width.
Making the width of content tables, the values of font-size, and padding responsive to device will make your content responsive as well.
In this example, the main content table’s width and padding are resized based on device width. All tables nested within this one will respond fluidly as long as they have percentage-based widths. Additionally, the font size changes to make it more legible on a smaller screen. Make sure to declare !important on your values to ensure they are not ignored or overridden by the default values in your body section.
< style>
@media only screen (max-width
320px
{
img[class=”desktop _ image”],
td[class=”cell” {
width: 320px
!important;
padding: 20px
!important;
}
p[class=”text”] {
font-size: 40px
!important;
}
}
< /style>
When using CSS to resize the elements of your design, you can code the body of the email as a fallback. When device width matches the parameters called out in the media query, the layout will be modified. In cases where media queries are not supported, the fallback layout will display.
Testing:
Render, Test, Repeat
Due to the wide range of rendering issues in different clients, you should test your design as often as possible during the production. Create a responsive skeleton and fully test it before inserting actual content.
Litmus and Email on Acid are two tremendous services that allow you to send a single email and view simulated renderings in most email clients and devices. These apps are immensely useful and a must-have for any email marketer.
That said, you should still use live tests in as many environments as possible. To make sure your design is universally compatible you should test them on as many devices and Web clients as you can. Viewing, scrolling (or swiping), and clicking in the actual client or device will give you a better idea of your opener’s experience.
For more information you can also download this free ebook, The Da Vinci Coding: The Art of HTML.