https://dodov.dev/blog/why-does-email-development-have-to-suck Skip to Content - * home * blog * why-does-email-development-have-to-suck * projects Why Does Email Development Have to Suck? Explaining all the 's and 's... Published on 17 Aug 2023 -/- lines long Illustration of a person falling in a hole, along with the texts " ", "", and "

". "Diving Into Email Hell" by s0.rumi (opens in new tab) First of all, if you're reading this because you unwillingly have to deal with email development, you have my deepest condolences for being one of the cursed souls condemned to suffer through this absurdity. I regard email development as the filthiest job you can do with a laptop. Nothing makes sense and you have to repeatedly test everything like a lunatic, much like trying to scrub dried up shit off a bathroom wall. Well, I hope the following will shine a light on this whole mess, give you useful advice, and relieve any potential suicidal thoughts you may be having. What is Email Development? In theory, developing emails should be very similar to developing websites. An email is essentially just an HTML document, like a web page, except it's visualized in an email client, rather than a web browser. However, both are capable of rendering, which is the process of turning HTML code into text, rectangles, and images, i.e. the visualization of the content. If you were a time traveler from 2005, developing websites and emails would've felt very similar indeed. Both browsers and email clients rendered HTML pretty much the same way and had the same functionalities. But while web standards(opens in new tab) evolved and browsers started implementing them, email clients didn't change much. When developing websites nowadays, we have support for tons of cool and productive features, such as grid(opens in new tab), flexbox (opens in new tab), dark mode(opens in new tab), transitions(opens in new tab), and they are supported in all major browsers. On the other hand, in email clients, these features are: * Not supported at all * Not working as expected, or * Not available in all email clients So if you want a reasonable portion of users to see your email as intended, let's say 95%, you have to stick to the most basic features of HTML and CSS. And even that isn't a 100% guarantee... With that said, let's see why the most terrible practices in web development these days sadly continue to be the best practices in email development. Why Elements? Email development is most notorious for its heavy usage of table elements and the never-ending string of and and 122 of

. Why? As explained in this article about rendering issues(opens in new tab) , Microsoft Outlook uses the same rendering engine as Microsoft Word. This means that opening an email in Outlook is basically like opening a document in Word, so you have to get into the mindset that you're making a Word document, not an email. You might think "wait a second, Word doesn't have many tools for layout and styling..." and you're completely right! But it does have tables. And only tables. Anything you want to be properly visualized must be a table. There's no other way. Deal with it. To prove this, here's how a modern email from Apple looks like when pasted in Microsoft Word 2013: Screenshot of a copy-pasted email from Apple in Microsoft Outlook. Apple invoice email in Microsoft Word 2013 Looks surprisingly not totally broken, right? Well, it's only because the HTML of that email contains 75 occurrences of

. Check the HTML(opens in new tab) and see what a mess it is. Why Inline Styles? Like a regular HTML document, emails can also have CSS styling, and if you're a reasonable person, you'd put them in the tag of the document. It'll work pretty decently, according to the "Can I email..." support pages for (opens in new tab) and