Email And The Fight For Standards

As a young web designer who cares about standards and accessibility, but also about paying the rent and having enough left over to buy some slick gadgets, I often find myself stuck between the proverbial rock and a hard place when it comes to designing HTML emails for a client.

You see, on one hand there’s a strong part of me saying, “No! Don’t do it! It’s not worth it to revert to web practices straight out of 1999. Tables are bad! Inline styling is bad! People hate HTML email! Your code is ugly! Fish are friends, not food!”

But then the devil on my right shoulder (wearing a blue dress, not a blue beanie) speaks up to say, “Dude, you need money if you want that [insert latest Apple product here]. Clients will not settle for text-only emails, or at least they won’t pay you for them. And besides, studies show that HTML emails are actually much more cost-effective for businesses. Suck it up a code a table, you sissy. Everybody used to do it, why do you think you’re exempt?”

To some of you, this whole discussion might seem to be flying 50,000 feet up, but here I’ll try to summarize:

In web design, it is now widely accepted that using Tables (grids of rows and columns, just like one you’d create in MS Word) for the structure of a website is a bad practice because it doesn’t allow for the separation of content (the text and pictures and videos) from presentation, and requires a ton of maintenance, among (many) other things. CSS (Cascading Style Sheets) emerged years ago as the solution to this problem, allowing designers to change the look of an entire site simply by editing a couple lines in a single external file (instead of every line on every page), and after a lot of activism in those early days, is now widely accepted as the proper way to code a site. Standards-compliant pages tend to load faster, have shorter development times, and are readable by every device now and in the future that has support for these standards.

The trouble is, most email clients don’t have this support, and some (like Outlook 2007) have even less support than their predecessors. Worse still, every single email client has vastly different support for various CSS/HTML elements, and will render your code in disgustingly problematic ways. So, by and large, many web design companies have abandoned email design, or if not, done it begrudgingly, ashamedly.

I’ve done my share, and it’s not glamorous work. Looking at what I’ve just written sometimes makes me want to cry (in pretty much the same manner that coding all-Flash sites does, but that’s a post for another day).

Finally, some of the big guns in web design and standards-advocacy are taking a stand and beginning to fight for standards support in all the major email clients, rather than ignoring the practicalities and pretending that HTML emails don’t or shouldn’t exist. That kind of denial sounds nice in theory, but in practice it’s totally flawed. Today, the default in nearly every email program is to send an HTML-formatted email. Any time you change the colors, or the fonts, or add some underlining or embed a picture - that’s HTML. So, if it has to exist anyway, shouldn’t it be done right?

These reasons (and others) are why the announcement of the Email Standards Project is such a big deal, and why I can hardly wait for the day when I’ll have coded my final bit of inline styling.

If you’re in the business, please join me in supporting this initiative. Here’s how you can help.