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…