Email Client Compatibility – HTML Friendly Emails

David — Sat, 21 May 2011 05:00:49 +0000

As a web designer, I actually do not frequently find myself working with email designs. So when my employer requested some HTML email templates, I had to do some research. I found a fantastic article on HTML emails that really helped me out. It was a bit long though, and I discovered some additional things along the way that I thought I’d share.

The first thing you have to do as a web designer when working with HTML emails is forget everything you know about modern coding standards. HTML email is years behind the curve. You’ll find yourself using inline CSS with limited shortcuts, tables instead of divs, and even deprecated attributes that haven’t been used in years.

The second thing you have to do is settle on a simple design. If you thought cross-browser testing was a miserable experience with four to five browsers (Safari, IE, Firefox, Chrome, and maybe Opera… plus mobile if you desire) try the dozens upon dozens of different email clients that all render differently! There are some good resources out there for cross-email-client compatibility testing such as Campaign Monitor or Litmus, but most charge, and if they don’t, they have a lot of restrictions like frequency of checking.

So here are the secrets to making your emails look good across all of your major email clients:

1. Use Tables For Layout because floating and positioning doesn’t work all that well. If you need something to appear next to another item (such as an image next to text) you should still divide that up into two tables. I know I know, it goes against everything you’ve ever known about modern coding standards and practices. But trust me, it’s the best way to go.

2. Use Inline CSS Only unless you don’t want your emails to all look the same. Some email clients will strip out the head tag or any external style sheet references, and others anything within a style tag. Keep in mind, many of these email clients are browser based, meaning they have their own custom CSS. To protect that CSS, they’ll strip anything out that could interfere with it before displaying it. And don’t even think about javascript…

3. Don’t Shy Away From Deprecated Attributes like width and border for your tables. When in doubt, just include it, because W3C standards do not really apply in the same way for emails as they do for websites. I always double my declarations. If I want my table to have no border, then I put that in my inline style declaration, and as a border="0" within the tag.

4. Avoid CSS Shorthand like "font: 14px Arial;" and instead do it longhand like "font-family: Arial; font-size: 14px;". Some email clients won’t read the shorthand CSS, though admittedly a majority do.

Here’s a bare, one column template that you can use with a single h1, h2, p, and a tag. Notice the XX and YY for your own personal preferences. The 98% width on the main table prevents email client bugs that create horizontal scroll bars.:





  
    
      Header Content Goes In Here
    
  
  
    
      Enter Your Header Here
      Enter Your Subheader Here
      Enter Your Main Content Here
      Enter Your Link Here
    
  
  
    
      Footer Content Goes In Here

In a future post, I’ll discuss ways to avoid getting your email marked as spam, as well as other best practices for making a good marketing email.

The Pros and Cons of Tables

David — Wed, 04 Feb 2009 13:00:00 +0000

When I started my job as a fulltime web designer, I discovered that my boss used tables for everything. This wasn’t that surprising considering he is a back end developer as opposed to a front end designer. I of course yelled at him (in my mind so as not to get fired) about how horrible tables are. Since then, I’ve settled more in the middle, and I figured I should offer my two cents on the debate of Tables Versus CSS for layout purposes.

First let’s take a look at the oh-so-obvious faults of tables, and why these cons are such an issue.

Con 1. Tables are incredibly rigid. Short of moving the content from one cell to another, changing the layout of anything within your table is incredibly difficult. Especially since you won’t want your layout to look like it uses a table, you’ll end up with rowspans and colspans everywhere.

Con 2. Table code can get messy. If you use tables for all your layout, then you’ll end up with nested tables all over the place. The code becomes hard to read, and almost impossible to edit.

Con 3. Tables have different default settings in different browsers. If you want your site to look the same no matter what browser your user is viewing it through, then you’ll have to go through at set padding, margin, border, et cetera to the values you want them to be. This is a hassle because of all the tags associated with tables. You’ve got table, tr, th, and td. Mind you, even if you don’t use tables, you should be setting default CSS values anyway to avoid cross-browser issues.

Con 4. Tables increase the size of your files. That’s right. Tables just often require more code. Even though the difference in load time for most people is negligable, it is still something to consider.

Alright, and now the benefits of tables, and why it is important to set aside your bias against tables and accept these pros.

Pro 1. Tables can be very helpful for certain design elements. Take rounded corners of any box for example. Though you’ll need anywhere between 1 and 8 images to make a rounded corner box (1 if the box does not need to expand, 3 if it expands in one direction, and 8 if it expands in two), tables will make the implementation of this a lot easier. Of course, you can use divs for this, but you won’t need to edit this table, just the content and images inside. Divs can float incorrectly in different browsers, ruining your rounded corner box, but the table won’t break.

Pro 2. Tables are great when you need to show… tables. That’s right, sometimes the best way to display information is in a table, and obviously the best way to implement that in the web is using… you guessed it, a table!

Pro 3. Tables make certain difficult CSS issues much easier. With tables, you can easily vertically center text, or ensure that two separate sentences of text will always appear next to each other horizontally. Obviously, there are tricks in CSS around this anyway. To vertically center a line of text, you can set the line-height to the same pixel height as the div it is in. So clearly, there is always a way around this problem.

When it comes down to it, every pro or con you find for tables doesn’t really matter. For every pro, using a little CSS magic, you can work around it. For every con, using a little effort or time can work around it too.

In the end, using floating divs is a much safer route to go for your layout. You can change the location of content very easily, your code will be cleaner, and make more sense logically when reading through it. But don’t knock down tables. Use tables for your overarching page layout (header, body, footer for example). These things won’t change as much, so tables are a clean and safe solution. Basically, tables aren’t 100% evil or amazing. Use them when appropriate, and don’t overdo it, and you’ll be just fine.

Bloggerrific » tables

Email Client Compatibility – HTML Friendly Emails

Enter Your Header Here

Enter Your Subheader Here

The Pros and Cons of Tables