One of the most common questions fielded by our Support team goes something like this: "My email looked just like I wanted in the editor and when I tested it, so how come it didn't look the same for my recipients?"
It's a common misconception that HTML is a "standard." Web developers have known for years that different web browsers (Internet Explorer, Firefox, Chrome, Safari, etc.) interpret HTML in slightly different ways. I like the way this web design tutorial puts it:
Your Web browser is a translation device. It takes a document written in the HTML language and translates it into a formatted Web page. The result of this translation is a little like giving two human translators a sentence written in French and asking them to translate it into English. Both will get the meaning across, but may not use the same words to do so.
There was a time when browser compatibility was a bigger problem for Web page designers than it is today. Years ago--during the so-called "browser wars," when Microsoft and Netscape were competing for market share--both browsers added their own proprietary "extensions" to HTML, instructions that only worked in their web browser. The difficulty faced by designers, trying to write HTML that would look good in either IE or Netscape, gave rise to a "Web Standards" movement, which held that:
If Netscape and Microsoft persisted in building ever–more incompatible browsers, the cost of development would continue to skyrocket, tens of millions would find themselves locked out, and the Web would fragment into a tower of digital Babel. In fact, we said, it had already begun to do so.
Adoption of Web Standards by the browser makers has eased the burden of compatibility testing on Web page designers. But what about those who write HTML for email rather than for Web sites? Unfortunately, there hasn't been widespread adoption of standards among different email clients (Outlook, Yahoo!, Gmail, etc). Worse, some of the recommendations of the Web Standards movement aren't fully applicable to the current state of email clients.
For example, one of the principles of the Web Standards movement is that HTML should only be used to define document content and structure, while CSS (Cascading Style Sheets) should be used for formatting. Therefore, use of HTML tags like <font> for formatting is no longer recommended. And while the <table> tag still has a purpose, it has nothing to do with aligning and positioning text on the page. But if a designer tries to apply those recommendations to email, they're not going to be pleased with how their message looks in, say, Outlook 2007, or Gmail, or Lotus Notes.
So what's an email designer to do? May I suggest:
- Test, test, test. Set up accounts on the free web-based email services, and use them to preview your email before releasing it to the world.
- Use tools like EmailAdvisor, which send your email to a seed list of addresses, then provide you with snapshots of how the HTML message looked in each of several popular email clients. Or...
- Use a simulator that doesn't require sending to a seed list--this is especially useful when the designer is not the same person who will be triggering the email send (and therefore doesn't have access to a seed list). Our designers at Delivra find a tool called "Email on Acid" particularly useful.
- Design for the lowest common denominator. Our built-in HTML editor purposely does not generate code that uses the newest instructions. That way, when you create an attractive-looking mailing, you have fewer worries of it breaking in, say, Outlook 2007 due to lack of support for certain CSS features.
Chris Broshears | Product Development

Comments for One HTML Email, Many Translations