What’s Your Email Code Longevity?

My fellow #emailgeeks, allow me to blow your mind.

I wrote this tutorial on building a fluid responsive email back in 2015.

There have been a few changes in email clients and rendering since then — Gmail adding media query support being among the most notable because it completely changed the way you had to code modern, responsive emails.

That said, despite the myriad of new best practices and changes to email rendering, my tutorial is every bit as relevant today and works as great as ever in every version of Outlook including the mobile app, in Gmail mobile and desktop, on Android, Yahoo and all of the other major email clients that Litmus provides compatibility tests for. I haven’t changed a single character in the tutorial code.

Let that sink in. An email I coded three years ago works fine today without any changes. Mind blown?!

The astute observer will note the tutorial email isn’t built with fragile, flavor-of-the-day HTML and CSS; it isn’t rife with quirks and workarounds. Instead, it’s written in Inkcite’s clean, easy-to-learn email markup language. Code that withstands the test of time is one of many advantages of using a higher-level markup language to create emails. It frees you from the hassles, headaches and tedium that most of y’all assume are a mandatory cross we have to bear as email developers.

While the tutorial code has remained stable and familiar, behind-the-scenes Inkcite has changed quite dramatically since 2015. Nine major releases, each chockablock full of improved rendering algorithms that transform your markup into clean, optimized HTML and CSS, effortlessly applying the workarounds and redundancies necessary to make the email render well everywhere it’s opened.

Code longevity and stability is matters, folks. I don’t accept that I should have to change the way I code every few months just because some updated email client wants padding prefixed with ffs-, repeated in 13 places and, unless it’s the second Thursday of the month, the P needs to be in uppercase. That’s absurd!

Making emails that render beautifully in a multitude of email clients is a solved problem. There are known and accepted best-practices for coding bulletproof buttons, background images, responsive columns that stack on mobile, better video previews, superscripts, web fonts and typography — all of these elements can be distilled down to a specific set of rules that dictate what values you set as attributes, where you can use CSS styles, when you can and can’t use CSS shorthand, how your VML should be configured, and what needs to be wrapped in Outlook conditionals or ghost tables. Those rules change from time to time, but your code doesn’t have to. Instead of chasing a moving target, craft your emails in a higher level markup language like Inkcite and let it’s rendering engine instantly and painlessly transform it into modern, responsive HTML and CSS. As an added benefit, your workflow is streamlined from its automatic link tagging, image optimization and 100% safe just-for-email code minification.

If the longevity of your own email code doesn’t stand the test of time or if you’re tired of re-solving the same problems over and over, you owe it to yourself to try Inkcite. It’s free and open source. Simplify, stabilize and accelerate your own email production workflow and see how enjoyable email development can be.

Like what you read? Give Jeffrey Hoffman a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.