Coding emails and email signatures can sometimes be a challenge. What email clients are capable of is limited when compared to web browsers. Further complicating things is the depressing fact that no two email clients are guaranteed to render your hard work exactly the same way.
Rules and Important Info
Structure
It’s common knowledge that email client rendering engines are oldschool (or worse), so tables are the most dependable way to code your layout. There are, however, some warnings against nesting too many tables. A big part of the reason why using divs instead of tables isn’t a practical choice is because you can’t clear floats. Padding is unreliable. Margins only work in some clients. For spacing and positioning it’s best to use tables and to set the width of each cell. Validate your code.
Paragraph tags can’t be reliably used for spacing of copy. It’s more consistent to use divs and soft breaks.
Images
No background images. This takes a little getting used to and makes some things really painful, so plan ahead when slicing and coding the cells.
Copy your images to a server and use a full web path. No relative paths and no embedding the images. Avoid PNGs, include alt text. Include the dimensions for each image.
Styles
A great deal of css can be used effectively but must be inline because some clients (most notably Gmail) strip the css blocks.
Here is a reference. Unless you can memorize this you really just have to get a feel for this by knowing what you’ve made work before and what won’t. It’s hard to check this every time you start adding code you need and hope works. But, if your compatibility testing shows a problem you can check here for an obvious cause: http://www.campaignmonitor.com/css/
Fonts and Text
Support for embedding fonts is pretty low. Web-safe fonts are the only ones you can use reliably for HTML text.
Webkit clients can sometimes resize small fonts for readability without asking. You can stop that with this: -webkit-text-size-adjust: none;
Miscellaneous items to be aware of:
- No scripts. Don’t bother.
- No need for doc type nor title
- Try to stay under < 100 kb
- No special symbols. No smart quotes.
Practical Guide for Designers (…if they’re reading this)
I’m going to list a few things that technically work but are very hard to get right in all clients. Then, show a couple of A/B examples of the design and the results.
First, extreme precision with font sizes and spacing is difficult. Email signature designs often come with some pretty intricate type settings and some very small type.
Also, there are issues with coloring and styling links. In gmail there seems to be no way to change links colors consistently.
Sometimes things just get too complicated
Certain versions were trashing what was working great in many clients. This had to be carefully built over again to work everywhere.
Links and References
Good General Practices
- http://www.campaignmonitor.com/design-guidelines/
- http://mattmedia.net/2007/08/23/8-html-email-tips-i-wish-i-knew-sooner/
- http://net.tutsplus.com/tutorials/html-css-techniques/6-easy-ways-to-improve-your-html-emails/ – general stuff with an interesting note about using Gmail’s inbox formatting to your advantage, however this little trick tells you to break one of the rules I found: not to use 1×1 spacer .gifs.
- http://css-tricks.com/133-using-css-in-html-emails-the-real-story/
CSS Support Guide
- http://www.campaignmonitor.com/css/ – this table shows what works where (and what doesn’t). This is a good reference but isn’t terribly practical for use while actually coding. Better used, for example, when your testing software (such as Litmus) shows you a problem in a client or clients and you aren’t sure what they problem is.
Premailer
- http://premailer.dialect.ca/ – this “premailer” automatically moves your css inline in addition to a few other things. This is really cool because it allows you to use styles more like you’re used to and have them put in-line easily and quickly before testing and sending.
Loading...
