Falsehoods programmers believe about email signatures (or: bad lessons in sleep hygiene)

Being a jack of all trades web developer for a small agency often times means having to delve into subjects best left to those horror stories told around a campfire. Like, having to manually retrace and vectorialize an intricate 36px by 36px logo for a client. Or having to retype by hand a multiple columns, 1000 records printed excel table. Or having to bring a boulder to the top of a mountain, just to have it roll it back down at the beginning because you left it alone for a few moments during a one-to-one agile meeting. Or...

Well, at the very bottom of such sisyphean path, here resides the most infamous job of them all: having to write an email signature in HTML.

For those who have little experience in this side of frontend development work, let's start by saying that writing any kind of HTML for an email client — for example, a newsletter template — still feels like you've never left the 90's (which, given the current climate, both literal and political, maybe it's not such a bad proposition).

The many issues still affecting this side of web publishing aren’t really a secret, despite the well-known unreasonable effectiveness of email marketing™. I assume you’ve heard weird stories about having to use tables to format emails, email clients using an HTML rendering engine taken from a word processor, or simply not supporting CSS properties depending on phases of the moon.

Indeed, much of the knowledge around writing HTML for emails feels closer to common folklore tales, being passed around in various ephemeral blog posts you've read somewhere but you can't find anymore. Much of the current knowledge on writing them comes from tools like CanIEmail or from guides written by email marketing companies, like Campaign Monitor, Litmus, MailChimp or MailModo. You better hope they won't change their core business, ever, because there's no mdn equivalent for HTML for emails.

So, we've reached the conclusion that writing HTML for emails is bad, right? Well, writing HTML for email signatures is way, way worse.

And by "worse" I mean "waking up nearly screaming at 5:00 am" kind of bad. Well, I guess having less than 20 hours of sleep in a week certainly didn't help. By 7:00 am I had come to the following conclusion:

• Get some sleep app (looked around and went for Endel) and try to sleep at lest a little more;
• Write down this article.

See, writing an email signature combines the issues I listed earlier caused by the rendering limitations — with other, even more precarious, pain points caused by the mail client themselves. I mean, sure, adding just a line of text isn't much of a problem. But what if your client instead starts asking for some multi-column contraption showing their company logo, his avatar, and enough certifications to partially resemble a north korean uniform? Things get very complicated, very quickly.

The wisest, and most approachable solution would be to use a mail signature service. This lets you sidestep the issue altogether, letting proprietary solutions like Exclaimer, Crossware or CodeTwo append your signature at the end of every email. Unfortunately for us, wisdom rarely gets their chance to speak in a Slack or Teams chat, which commonly manifests in the following circumstances: managers too cheap to spend 100 bucks/year for getting a working signature for their thousands-euros worth communications, an IT situation where most of the staff is left (literally) to their own devices and configuring a common mail server configuration is nowhere near feasible, or somewhat valid concerns regarding the GDPR compliance of such services are raised.

So we're back at step one: write the signature in something resembling HTML first, then apply it to each email client. As I already said earlier, the latter is usually as complicated as the former.

In case of Apple Mail, trying to place a complex HTML signature feels closer to a sequence out of Mr. Robot than a boring editing procedure. Trying to do the same for the signature box in the gmail web client will cause you to question your own sanity, considering that the final output is governed by heuristics which appear to be unclear to google themselves. Microsoft Outlook offers a near-unending series of possible outcomes depending on whatever yearly version is being used, what other applications are currently available, which operating system and service pack or Office updates are currently installed, causing your signature to mutate out of its own volition in time. Taking into consideration the mobile and web version of each of those clients adds another layer of unneeded complexity to this already maddening task.

Writing a guide to trying to manage the issue would be a chore of quixotic kind – By the time I had finished writing it, there would be some changes in some client already that would require a rewrite.
My best suggestion is to truly keep an open eye and make sure to keep in mind the following rules, written in the falsehoods programmers believe about [topic at hand] that is so fashionable nowadays. Some of them apply to HTML email in general, but make even more sense in the context of writing signatures. Here's the list:

All the following assumptions are wrong:

• An email client has the same HTML, Javascript and CSS capabilities of modern day web browsers.
• At least, web-based clients should.
• Even if they're not, they at least have comparable features to a modern web browser.
• They fully support at least basic HTML features, do they?
• Failing that, we get the same image formats^[1].
• Even if we limit ourselves to pictures stored as jpeg and png, they should behave mostly the same way in every client.
• Embedding the images should at least work around every other issue.
• The signature of your email sports the same limitations of the body of your email.
• The client can easily distinguish between your signature and the content of your email.
• Otherwise, it should treat your signature the same way it treats the content of your email.
• Any mail client can easily accept HTML for the signature.
• Well, if it can, it accepts any HTML.
• Or at least a clearly identifiable subset of it.
• The subset is somewhat stable and keep expanding between releases of the same mail client.
• Your signature is stored the same way you've originally written it.
• Ok, it is sent the same way it is shown to you.
• Uhh... It is displayed the same way it was received.
• Once received, it is stored like the rest of your message.
• The web version of your mail client sports the same features of their respective native version.
• It supports the same signature-specific features of their native version.
• Similarly, the mobile version of your email clients has the same signature capabilities of their desktop clients.
• Mobile versions support the same (or close to the same) features between operating systems.

I'm reasonably sure I'm forgetting some other extremely obvious limitations; expect this list to be updated in the near future. At the very least, after a decent amount of sleep hours.