Get off the <table>

As I publish this I've just given a brief presentation at Litmus Live in London about building emails without tables.

I've made a good start but the code isn't really production ready just yet so I'd like to open it up to the #emailgeeks community, so others can try and build on what I've started.

Why do we use tables in email?

The short answer is Outlook.

Instead of using an HTML rendering engine to render email code Outlook uses the Microsoft Word rendering engine. This only applies to the Windows desktop version of Outlook and the Windows 10 Mail app. Outlook on Mac and both use HTML rendering.

So because they don't use proper HTML standards, the layout has to be built using <table> elements.

What's wrong with tables?

They use more code

In email we're limited to ~102kb of code so any reduction of code means we can include more relevant quality content.

They aren't naturally accessible

<table> elements are not designed to be used for layout so assistive technology will treat them as data table unless you add role="presentation" you can read more about email accessibility here

They don't inherit styles well

All browsers and email clients come with some basic default styling. This results in having to reset things like font settings every time a new table is added.

They can be tricky to manipulate

When building a responsive layouts you often want to move parts of the content around. This can be tricky when using tables, particularly when you sometimes don't have control of the <!DOCTYPE html>

The Code

So I'm going to focus on getting a central 600px wide container to wrap our content.

To start off with the code that will work in all other email clients;

<div style="background:red;max-width:600px;margin:0 auto;text-align:center;">  

Then to get outlook to respect the width we want we add this code


At this point outlook will actually convert the <div> element into a <table>.

Currently I don't have a way to do multiple columns inside our container so to be able to add a table inside here, we add this;


Then to centre align the container we use this;


Then to stop additional content floating alongside this we add;


And that's it, you now have a 600px wide centre aligned container for you email. Here it is in it's entirety.

<div style="background:red;max-width:600px;margin:0 auto;text-align:center;  
  <!-- Content -->

However there are still a few issues that prevent this form being production ready.

Issues to solve

As these are solved I'll try and update this article and give credit.

  • Remove blue outline
  • <body> colour for Windows 10 mail
  • Changing the background for a section
  • Background images
  • Multi column layout inside the container
  • Padding that holds the background

Get involved

Take the code above, find bugs, find solutions and get involved. I want this to be a community effort.

Add to the project on github, write up your findings on your blog, share your them in the comments below or on twitter using the hashtag #GetOffTheTable. There's also a discussion on the Litmus Community

A few resources to help get you started

Accessibility in email: Part II

Coding email for accessibility

We recently posted an introduction to accessibility in email. This post if a follow up to that.

Accessibility is not often talked about in relation to email but it should be. As email developers we spend hours getting an email to look just right in a client with less than 1% market share but very few of us will spend a few minuets making the email accessible. I'll admit, I've been guilty of this too in the past. So I've put together a quick guide to get you started with some basics.


Tables are not meant for layout, they are designed to be used for displaying tables of data, so assistive technology will treat them as such, giving context to each cell in the table. This makes navigation slow and complicated, you need to navigate to each cell, enter the cell to read the content, then leave it then move to the next one. Whereas with a div based layout you can simply move from one piece of content to the next.

There is one simple and quick fix to this issue. Add role="presentation" to each <table> and it will be treated like a div based layout.

You only need to add it to each <table> element not every <td> so it’s a very quick and simple change to make. Go and do it now, you’ll dramatically increase the accessibility of your emails.

I made this video to show the difference role="presentation" makes to a screen reader.


N.B If you do have a table used as for it’s intended purpose, as a table of data, then don’t add this role.

Alt text

You’re hopefully already using alt text to describe images for people who have images turned off in their email client. Well that’s just the same for screen readers, simply use the alt text to enhance the experience by replacing the function of the image. Remember to be descriptive.

There are however times when you don’t want alt text, a spacer gif for example. Simply leaving the alt attribute off the img tag isn’t good enough, in this case the screen reader will read the full URL of the image, not good. So instead use alt="" to let the screen reader know this is intended to be blank.

HTML1 Semantic tags

There is often a bit of debate about whether to use <p> and <h> tags in email. I’ll settle that for you now. Do it!

Ok so you may have to add some additional styles to get the layout you want but that’s not hard.

So why use them? If you look at this article you can see there are a few heading, if one of these interests you, you read it, if not skip to the next one. If you’ve already read the article and just want a recap on one section you can quickly and easily find that. This can be done easily with a screen reader too but if there are no heading then the user will have to read the entire article.

HTML5 Semantic tags

When HTML5 came out, they introduced a series of new semantic tags to give better context to the code.

<article> <aside> <details> <figcaption> <figure> <footer> <header> <main> <mark> <nav> <section> <summary> <time>

This means the user can have clear context of weather they are navigating in the <header> <footer> or <main> part of the page for example.

Unfortunately it’s a bit too early to start relying on these in our email code as some clients will strip them completely (more details on support below) so instead we can use the role attribute. For example role="header" role="footer".

So when and how do we use these? This is quite an in depth topic so I’d say use sparingly to begin with, you don’t want to end up confusing people with misuse of these attributes.

One thing I should point out though is avoid using role="main". The accessibility spec says there should only be one main element per page so this could end up being confusing as we'd hope the webmail page or email app has already defined a main element.

So if not main what do you define your email wrapper as? I’m still undecided. I would think role="article" or role="section" would make the most sense but webmail clients are already wrapping your content, so maybe we should avoid any double wrapping.

Gmail wraps your code with role="listitem" inside role="list" but only a single list item in the list which seems odd to me.

Yahoo! use role="presentation" on a div and that is inside role="main" which is also odd. There should only be one main per page and a div is presentational by default. (older version) doesn’t appear to use any HTML5 tags or roles anywhere in the page, but this site is nearly phased out so I'll forgive them. (newer version) uses role="document" this probably makes the most sense but I'm still on the fence here.

So as you can see there is no agreement between the major webmail clients on the best structure to use, so I’m going to hang back on this until I’ve done some more research. I'll try and update this section as I learn more.

Email client support

Well we’re off to a good start as <h> tags, <p> tags and alt text are supported everywhere, so if you’re not using them already, please start.

I ran a quick test on some HTML5 elements and found Inbox, AOL, Yahoo,, Outlook 365 GMX, and Alto, all strip HTML5 elements. They remove the tag completely so you’ll loose any class, id, role or inline styles applied to these but do leave the content. Out of that list, they all also strip role from a div, with the exception of Inbox.

But remember role won’t affect the visual appearance of your email in anyway, it will only enhance it for assistive technology so there’s no reason not to use it.

Gmail supports most HTML5 tags but removes, main, nav details and summary.

iOS, Apple mail, Outlook Mac, Android, Samsung, BB10, all look like they have great support for HTML5 tags and the role attribute. So if you are a user of assistive technology these are probably the ones to use.

In summary

Accessibility it is a very big and complex issue but making one small change today can have a huge effect. So go and put role="presentation" on all your presentational tables right now, you don’t even need to retest anything it just works. If you use snippets or modular build then this is even quicker.

Then moving forward in your next build start thinking more about semantic elements, maybe just use a few <h> and <p> tags to begin with if you're not already using them.

Small steps can have a big impact. You don’t need to strive for perfection at your first attempt, do something small today, then add a little something extra next week and so on. It should become a part of your day to day workflow.

Litmus Microsoft Partnership

I'm hopeful but a little sceptical

Last night I logged on to watch a live feed of the Litmus, Email Design Conference in Boston. There Caitlin Hart, Program Manager from Outlook announced a partnership with Litmus to improve the rendering of Microsoft email clients. More details of that partnership here.

My thoughts the day after the announcement:

The Good

Firstly it's a great step in the right direction, a few years back the IE team reached out to web developers and ended up with a much better browser, better for developers, better for users. So lets hope Outlook can follow suit and do the same.

Outlook has recently been reducing the number of email clients. Live mail is gone and Outlook 365 and have sort of merged from a rendering and UI perspective. This means less testing on our side and less to maintain and therefore more time for bug fixing and improvements on their side.

This is also setting precedent for other email clients to follow. There is already good communication between developers who build website and those who build the browsers, hopefully this is the start of that relationship for email.

The Bad

However I am a touch sceptical. Back in 2009 (before I got into email) there was a campaign, the site is no longer with us but you can read more about here.

The campaign seemed to gather some good momentum and even got a huge poster put up in the Outlook office. But then Outlook 2010 came out with the same bugs as 2007 and if anything it's got worse since then with a number of 120dpi rendering issues coming in recent versions.

But that campaign was focused at the desktop client. I don't think we can do much there. Outlook 2016 STILL uses the Word rendering engine so they seem set on it and even if they do change to HTML rendering, people will be using 2016 for a number of years. We still see a few people using 2007!

The Ugly

Ok so a quick note on Outlook desktop and why I don't like it. Yes it's a pain to code for but it's quite predictable and most fixes are well documented.

My issue with it is it dramatically increases the code weight and dramatically reduces accessibility for every single email we send, no matter where it's opened. Yes you can fix your design for Outlook desktop but in doing so it means a worse experience for every other person receiving that email.

Billions of emails are sent every day that could be half the file size, millions of those are opened by people who struggle to access the content because of the way they are coded.

At Rebelmail we've done a lot of work to improve the accessibility of our emails and reduce the weight of our code but it's very complicated. Being able to use semantic HTML would lead to a dramatic improvement.

Sorry bit off topic there, rant over.

But I'm staying positive

We can all agree the Outlook desktop app is bad for people developing HTML email and I doubt anything will be done to fix that soon. What we should be focusing on now is the webmail clients and the apps, those can be fixed and those fixes can be rolled out across every account.

I'm sure the Outlook team will be inundated with bug reports from email devs, I hope they are ready for that. I know a few people including myself have already reported a number of bugs to Caitlin and before her to her predecessor Julia, so I'm hopeful to see some fixes rolling out soon.

And Finally

Remember the big difference between this drive for better rendering and the campaign is Outlook is involved with this from the start. You could even say they initiated it when they reached out to Justin Khoo last year.

I'm hopefully but I'm not going to let myself get too excited until I see the first bug fix roll out.

Accessibility in email

An introduction

I started writing this the day after I got back from Amsterdam where I was speaking at the brilliant CSS Day conference. I learned a lot, I met some amazing people and I did a talk on interactive email, which can be scary in front of a few hundred web developers (who notoriously hate writing email code) but it went down really well.

Out of all the things I learned at the conference, one thing really stuck with me, accessibility. Léonie Watson did a great talk on the subject, I also had a chat with her in the bar afterwards about accessibility in email and the lack there of.

What is accessibility?

Not everyone can easily use a monitor, keyboard or mouse, some people use what's classed as 'assistive technology'. For example people with visual disabilities may use screen reader software to read the text on the screen, or a magnifier to dramatically enlarge it. People with physical disabilities may have to navigate using alternative input devices such as joysticks, eye tracking, a sip 'n' puff device or specialist keyboards.

Accessibility in email is simply about building emails in a way that can be accessed by these assistive technologies, allowing more people to access the content being sent.

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.

Tim Berners-Lee, W3C Director and inventor of the World Wide Web

You're probably already writing code so people using Outlook, Gmail and other clients with poor rendering can read your emails, think of this as an extension of that. It's just increasing support to get your message to more users.

What can we do?

Email accessibility is bad because of two factors. Email developers not writing accessible code and email clients not supporting accessible code.

I often spend my days working out better ways to write email code so now I'm focusing my attention on making that code accessible too. Once the code is built and being sent it'll hopefully be easier to convince the email clients they need to catch up too.

I will then share my findings and encourage others to do the same.

Absolute positioning in email

You can't use absolute positioning in email.

Well actually you can a bit. It is supported in modern email clients; iOS, Android, Applemail, AOL etc. But it still gets stripped from the likes of Gmail,, Outlook 365 and obviously Outlook desktop.

Yahoo mail is a funny one, it supports position:absolute; but not top bottom left or right therefore rendering it useless.

It was actually when testing the below hack that I found Yahoo supports position:absolute; and prematurely shared the news on twitter without realising the debilitating caveat. So by way of apology here's how to do position absolute in Yahoo and almost every other email client.

Absolute positioning that works everywhere

(Except Outlook on desktop pc, but what do you expect from Microsoft Word rendering)

So first of all you need to set a container to position against.

<div style="width:300px;height:300px;">  

Then place an element inside that, set display as inline-block and position it with margin-top and margin-left.

<div style="width:300px;height:300px;">  
    <div style="width:100px;height:100px;margin-top:100px;margin-left:100px;display:inline-block;">

N.B. Unfortunately negative values in the margin won't work in Gmail, or 365.

The element is now behaving similar to position:relative but we want position:absolute so as not to affect the flow of any neighbouring elements. To achieve this wrap the inner element in a div with max-height:0;max-width:0 this now mean that div takes up no space on the page, but the overflow can still be seen.

<div style="width:300px;height:300px;">  
    <div style="max-height:0;max-width:0;overflow: visible;">
        <div style="width:100px;height:100px;margin-top:100px;margin-left:100px;display:inline-block;">

You can now place multiple elements in that container and position them absolute. In this example I've added outlines and semi transparent background colours to clear display the outcome.

<div style="width:300px;height:300px;outline:2px solid black;margin:0 auto;">  
    <div style="max-height:0;max-width:0;overflow: visible;">
        <div style="width:100px;height:100px;margin-top:100px;margin-left:100px;display:inline-block;outline:2px solid red;text-align:center;line-height:100px;font-size:50px;background:rgba(255,0,0,0.2)">
    <div style="max-height:0;max-width:0;overflow: visible;">
        <div style="width:100px;height:100px;margin-top:150px;margin-left:150px;display:inline-block;outline:2px solid blue;text-align:center;line-height:100px;font-size:50px;background:rgba(0,0,255,0.2)">
    <div style="max-height:0;max-width:0;overflow: visible;">
        <div style="width:100px;height:100px;margin-top:50px;margin-left:50px;display:inline-block;outline:2px solid green;text-align:center;line-height:100px;font-size:50px;background:rgba(0,255,0,0.2)">


Ok so it still doesn't work in desktop Outlook but it does work pretty much everywhere else I've test.

But please do use this wisely. Do consider Outlook, perhaps a VML fallback or simply using Outlook conditional comments.


Thanks to JK who pointed out in the comments that the Yahoo overflow update affects this. So I've added overflow: visible; to the above code which fixes that problem.