The Hybrid Coding approach

Media queries are a fantastic way to optimise layouts for smaller screen sizes. They are the current digital standard after all, the web community may already (and indeed always) be looking for the next way (flexbox etc.), but they are ideal for email as they essentially trigger a set of CSS rules dependent upon screen size (true or apparent), without the need for javascript or anything external.

However, there are some “smaller screen scenarios” where media queries aren’t supported (e.g. the Gmail App) or indeed only partially supported (e.g. some Android device native mail apps). Partial support means that the media query is parsed but the Doctype is stripped, forcing quirks mode (or equivalent) and dropping some attributes e.g. making elements not behave like blocks when they are being told to, causing real layout problems.

This is frustrating to say the least.

As ever, there are ways around this. Most importantly to design and code to allow for optimisation without media queries being essential. Of course they can still be added in to add flourishes as they are read proportionally more often than not another good reference here, it’s best not to lose sight of this, but the core of the email will work without them. This can sometimes be a great “get out of jail” if the end user is requesting or you are just some kind of maverick who doesn’t want to let things like the Gmail App stop them.

In order to do this, it means making the email out of flexible percentages in the first place. The problem with that is, as anyone who has ever coded an email will tell you, without fixing at least some of the widths your email will not render very well and unfortunately, fixing a width means that the email will be rigid unless broken by a ruleset.

So to get around that, the logical solution is to use max-width and min-width to impose rigid baselines, but allow movement. Unfortunately this doesn’t work in Outlook. I mean really doesn’t work, it wrecks it. Luckily, there’s a 2 step solution to this:

1. Use conditional statement to impose a fixed width for Outlook and retain flexibility everywhere else.

<!--[if mso>
<table width="640" border="0" cellspacing="0" cellpadding="0">
<!--[if mso>

This is as a good solution – however, it doesn’t work in the older Outlooks (pre 2007). This is where the next stage of the solution comes in.

2. Use a second conditional statement which targets the older rendering engine

<!--[if (IE)]>

etc. in effect then double wrap which gives a very neat solution for a one column email.

There is also a step number three for Apple:

3. Add in an IOS fix to the body tag and a min-width media query for Apple Mail or it seems to get confused as to what 100% really means…(got this from a particularly good presentation by Fabio Carneiro):

<body width:100%; min-width:100%;>
@media screen and (min-device-width: 640px), screen and (min-width: 640px) {
*[class=wrapper]{width:640px !important; height:auto !important	

Now you can make full width images a % width e.g.100%, leave off the height to prevent skew, and apply max-width inline to help prevent the image from popping.

Here’s a very simple example to see optimisation without media queries:

In order to reorder and stack multiple columns of content you will need to get a bit clever – so I wouldn’t recommend it. Still there? Insisting? OK… so one way we have found is to use a combination of fixed and fluid widths.

So the theory is have a flexible wrapper and then make the blocks inside it inflexible (and separate) so that they are forced to stack. Issues here are that the fixed width of the element now becomes the new “min-width” of the email. Blocks sitting side by side have their own considerations especially in Outlook. You can get around that here. Apologies, I probably repeat myself, I wrote this a while ago and left it on the shelf but the essence is: using false structure to shore up the email.

This will work quite well with 2 columns, but not so good with 3 depending on your overall email width. Arguably, the recommended rule of 600px-650px doesn’t count if coding in the hybrid way, as we are taking all screen sizes into consideration. 600px might be “best practice” for making an email mobile friendly, but if we are specifically making sure that the email is optimised and actively changing layout for all sizes then we can easily and safely go bigger say 900px (300 x 3). Obviously, not recommending that you go bigger than that if at all, as we are still limited by the physical realm, and some people have very small laptops running Lotus Notes, but I digress…

As we can’t resize an element safely without a media query telling it to or indirectly telling a parent element do so, so we would be looking to make the blocks 300-320px in width to keep it looking good on a small screen. There are other considerations here, such as partial optimisation which we see a lot with certain android combinations. Here we would get the stacking, but as the elements will not be resized, and indeed certain widths outright ignored, we can end up with quite a blocky looking email. This can be homogenised with careful use of background colour and images to force some widths of the pods, but it’s really not ideal and requires extra design considerations. But then, I’m sure that’s a whole other blog post…

  • Pingback: How we made the #emailweekly newsletter | Email Design Review

  • Pingback: Render Testing Mailbox for Mac | Email Design Review

  • Pingback: Things we learnt at #TEDC14 | Email Design Review

  • Pingback: Litmus Email Design Conference - #TEDC14 Twitter Takeaways

  • Pingback: “The Hybrid Coding approach” Notes | Email Hindsight

  • Pingback: Making Responsive HTML Emails | Benjy Stanton

  • Pingback: How to hide and show content on mobile devices | #ActionRocketLabs

  • Pingback: 50 Completely Awesome Tips From Completely Email 2014

  • Pingback: Can you just make it responsive? | #ActionRocketLabs

  • Pingback: Google’s embarrassing email problem | Email Design Review

  • Pingback: 18 Key Hacks to Make Your Email Mobile-Friendly - Equisense Management Inc.

  • Pingback: 18 Effective Hacks for Mobile Friendly Email Marketing

  • Pingback: Mobile Email: Tips on getting started | MarketingSherpa Blog

  • Pingback: Coping Mechanism for Mobile Emails | Email Monks Blog

  • Pingback: 4 column Hybrid shape with an hack | #ActionRocketLabs

  • mvicidomini

    Would it be possible to have 2 asymmetric columns with this technique?

  • Pingback: Will there ever be an email standard? | Email Design Review

  • Pingback: HTML Email Template crush in Gmail - DexPage

  • Bhuvan Desai

    It seems this technique does not work for most of templates that have right column to be placed on top when viewed on mobile. Also it does not work when there is background images to be called in emails.

    Do you think this technique should be applied as regular practice; since as per our experience it only works for single column design and not much recommended since it increases the lines of code when rendering on outlook due to use of outlook specific tables too.

  • Mike Ragan

    Hello! That’s a good question – technically, the simplest way is to make no block greater than the minimum width of the unoptimised environment. So an asymmetric 2/3 1/3 split e.g. 400px + 200px would not be recommended. But it is possible. See further posts on this, whereby we drop out widths on the inline divs, so have done 2/3 image and 1/3 text using max-width to cap the image, but the text box hard coded to 200px in order to keep it right. This means that text box will look a little small when stacked. The difficulty is not having media query to resize elements means that they become a lot more volatile, but I think that with the number of tested/confirmed shapes and layouts around, we are so very close to a complete solution. I will post one way to achieve this as a quick post soon – thanks again for the question!

  • Mike Ragan

    Hi Bhuvan – thanks for the comment – please review some other more recent posts/codepens – we can reverse stack right to left without media query. Background images shouldn’t be any more of problem than they are already, what is the context?

    It is my feeling that this will be standard practice amongst people who want to make things work now, the future is not written – this approach was borne out of getting Outlook to work with table align (optimising without doctype), which then progressed on to gmail app (optimising without media query). In the email rendering world things can change very quickly, but another plus point for hybrid is that it doesn’t matter about the fractured rendering environment is, it just raises the bar – therefore empowering the developer.

    A few design challenges are raised, and the level of skill required to develop increases accordingly, but the result has value with the rise and rise of gmail.

    Re: the few extra lines of code for MSO tables as wrappers – i would say thats really not an issue all things considered.

  • mvicidomini

    Hello Mike,

    thanks for yours answer.
    First things first: hybrid approach saved my life.
    Second: I’ve been experimenting with hybrid approach and asymmetric columns myself this las weeks, and as you say, it is technically possible; the problems I have with the results are of aesthetic nature, due to the lack of control over alignments. It’s probably more a personal opinion than a real problem, but I’ll share it here anyway hoping it might be helpful.

    Imagine an asymmetric layout where the left, smaller column holds an image, and the right, wider columns holds text, and the text needs to be left aligned in larger screens, where the two columns are not stacked.

    In smaller screens, where the two columns are stacked, I then had 2 possibilities:
    - If I aligned the image to the center, it didn’t look aligned to the text
    - If I aligned the image to the left, it looked aligned to the text but the whole thing didn’t look aligned to the screen, since the image left a big empty space on its right side.

    In both cases, it looked like a mess, at least in my opinion. Adding some media queried css to change the alignment of the text solved this problem, but not in those email client/app that doesn’t support media queries (read Gmail).

    So in the end, while technically possible, I wouldn’t use asymmetric columns with hybrid approach, unless I could have both columns always aligned to center, which I don’t like, but this is just a personal opinion.

    With symmetric columns, this problem does not exist since the layout would look perfectly aligned both with left and centered aligned text.

    If you’re planning to write a post on this, I could share some screenshot with you if it can help :D

  • Pingback: The most common HTML email rendering issues - Glenn Smith

  • Shameer R

    Hi Mike,

    I have run into a little wall while coding using the hybrid method. I recently coded a two column template specifically for Gmail app. The problem is in iPhone 6 and 6+ the layout seems to 50% each for the column while iPhone 5 shows it at one column. My template has the columns as 50% in the body, if i make it 100% then the Gmail desktop client shows it as 100% as well.

    Any help will be appreciated.


  • Mike Ragan

    Hi Shameer, interesting – I have a few ideas why that might be happening. Would you mind emailing me the html: and I will publish a generic/white label example fix in a codepen for you?

  • Shameer R

    Hi MIke,

    I have just sent you an attachment to the above email.

    Looking forward to your input.


  • Rob Arroyo

    Hi Mike,

    Have you had issues with using this method? It seems that is ignoring the styles in the head and the conditionals.

  • Pingback: Email design : l’approche mobile first | Email Designer

  • St.G

    You can use this to set up Outlook-related scaffolding – no need to double-bag it! ;)

    (Edit: Web mail clients run in IE do not show the code contained therein. strips it out altogether. This seems to be an effective way to target Outlook desktop clients and Notes, somewhat surprisingly.)

  • Pingback: 3 solutions pour améliorer le rendu d’un emailing dans l’appli mobile Gmail | Email Designer

  • Pingback: Don't get lazy - Just another email blog

  • Pingback: Email at the Turning Point – RodriguezCommaJ

  • Pingback: Email lives - email design dos and don'ts - Movio Blog

  • Pingback: Newsletter code | Pearltrees

  • Pingback: Email Toolbox - Tristano Vacondio