Hello and welcome to episode eleven of Front End Center: Email, Cruel and Unusual?!

I’ve been working on a pet project this week to update some branded email templates with a more recent style. The prior versions were mostly text-based content templates to save time and focus my thoughts for a variety of situations. I’ve since polished up a bit on the oh-so-sexy skill of HTML email building, and thought this was a perfect excuse to do a comprehensive deep dive and make some really nice templates.

For those of you who’ve brushed shoulders with HTML email before, you might already have begun smiling at my optimism. Email and convenient, organized design go together like oil and water. On one hand, there are some pretty good looking, mobile-responsive email designs out there! On the other, viewing the code that makes it happen is implicitly taking your sanity into your own hands.

Even a basic HTML email with minimal layout and static content is actually held up by piles of tables, columns, cells, and outdated HTML attributes. The convenience of CSS is also thrown out with the bathwater, as you have to inline your styles on each specific element.

So how did email design and development get so thoroughly detached from the modern web? It’s not unlike opening your browser to find that suddenly all the old coding fads of the turn of the millennium never went out of style. Also, Microsoft Word is one of the most popular web browsers, somehow.

Let’s start from the big picture and work our way down. We’re relatively blessed at this point in the internet’s history. There’s a finite amount of genuinely popular browsers that you can regularly expect to support. Even better, most of the current versions of these browsers actually AGREE with each other. Spending days tweaking your code for a hundred cross-browser issues is no longer a constant necessity.

Where the internet has experienced a momentary blossoming of sanity, email took a dive off the deep end of the crazy pool.

Largely due to the customizable and personal nature of email as a medium, there are a LOT of email programs. When the internet worries about desktop versus mobile, email worries about hundreds of apps PER operating system PER platform. On top of this, most of the big players in email space don’t agree with each other on how best to handle email HTML rendering.

Let’s take a look at some of the underlying issues and see if we can understand their sources.

Close and dear to my heart, Microsoft and Outlook make a great place to start digging. They provide an utterly staggering amount of email service, especially in the business sector. Like many other Microsoft offerings, the experience is good enough to be ubiquitous, but also challenged enough to give rise to constant competition.

Until the last few years, Outlook ran HTML rendering through Internet Explorer. Even if IE was the red-headed step-child of modern browsers, at least that meant you could anticipate it in the same way you already did for a standard website.

Then, in 2007, Microsoft made a change. You thought I was joking about Word being the most popular web browser earlier? Sorry, I wasn’t! Word’s engine now renders the HTML content of emails for Outlook, giving it possibly the most technically depressing share of world-wide “browser” use I can imagine.

The roots of this change make sense, from Microsoft’s business perspective. Prior to 2007, they relied on a mix of a dedicated (but limited) Outlook HTML engine, outsourcing parts to Word, or otherwise Internet Explorer. Rather than juggle two very similar development efforts while translating them to work with a third, they decided to focus on one work-horse: Word.

A few issues we encounter thanks to this transition include:

• GIF images don’t animate.

• “Advanced” CSS of any kind is unsupported.

• HTML Accessibility methods are limited.

The main causes here focus on security and relevance to email functionality. Microsoft wants to minimize the methods that can be used to load scripts, fake content, or otherwise compromise a system directly using their tools.

Another source of equal frustration and joy in the email world is Google and their Gmail service.

Where Microsoft rules the roost of business and dedicated software services, Google is nearly unrivalled in the browser. Handing out free candy like Gmail put them head and shoulders above any competition, but also opened them up to some unique challenges.

Unlike Outlook, Gmail operates like you would actually expect when rendering HTML and CSS! That is… when you can get your CSS through to your user! Gmail has a nasty habit of removing any and all CSS that isn’t directly inlined onto your otherwise clean and semantic HTML.

The underlying cause comes back, mostly, to user security and safety. Rather than make small, fragile adjustments and end up in an arms-race with spammers and hackers, Google opted to go with a method that didn’t leave an opening to negotiate.

Before Gmail renders your HTML, it removes a couple of items from the document. First goes Flash, then object and embed tags. Next, as one might expect, JavaScript is removed. Finally, Google swings for the fences by removing all <style> tags, as well as the <body> tags and the entirety of the documents <head> section. Essentially, web design lobotomy and then some! Whatever survives is then handed off to the browser to render as you’d safely assume.

Microsoft and Google have taken very different approaches to solve very similar issues. Microsoft decided to use its own resources, and additively build features slowly into the Word HTML rendering engine. While the growth isn’t particularly breathtaking, the development team does actively take feature requests and make changes to the underlying code. Google relies on the browsers it lives in to handle the mechanics, while negatively removing what it views as security and usability concerns.

Compound these branching solutions with every other competitor in the email space, and you begin to see how massively issues can scale. When an one single email may be rendered in hundreds of applications with unique and sometimes nonsensical rules… the toolbox we can work with becomes severely limited.

Even then, creativity can sometimes be at its best in challenging positions. Just because it’s not semantic, clean, or easily reusable, doesn’t mean email development lacks value. If anything, it’s a microcosm of the conditions on the web that led us to the advances we have today. What additional lessons can we learn while designing and developing in both modern and rather contrived environments side by side?

Like last week, I’d like to make a shout out for any listeners to check the episode description or go to http://fec.fyi and fill out the survey there! It’s a very short set of questions, focused on the content and quality of the podcast, and what I can do to improve the experience! I greatly appreciate Everyone who takes the time to fill it out.

Until next week, thanks for listening! This has been Chris Landtiser, and Front End Center.