I generally try to reach association audiences with my pieces on this site, but nearly a year ago, I wrote a blog post that got a bunch of people talking outside of it.

The reason? I hit a pretty obvious pain point both inside the association space and outside of it: Email design is just the worst.

So why am I writing about it again? Well, it appears we’re about to turn a corner. My message of frustration, along with a few others, appear to have finally gotten through to the makers of one of the most popular email clients—specifically, Gmail.

Last week, Gmail’s development team  announced that the system would finally be getting support for two features that developers have been clamoring for:

• Media queries, the cascading style sheets (CSS) specification that enables responsive design on mobile devices
• The <style> tag, along with support for CSS classes and ID tags, which are considered fundamental web design building blocks

<style>

The second item is actually a bigger deal than the first, though Gmail product manager Pierce Vollucci didn’t really take time to mention it in his blog post, which mostly focused on the responsive design benefits.

“These changes will make your email experience as comfortable and intuitive as possible,” Vollucci wrote in his post. “And as responsive design becomes more common, you’ll continue to see emails that fit better on all your screens and devices.”

The newly supported CSS properties, heading to mobile and desktop platforms later this month, will most assuredly improve the process of designing emails in the long run. It won’t make things perfect, however—the Windows versions of Outlook, which render pages using the same engine Microsoft Word uses, will ensure we’ll be designing emails using tables for years to come.

Nonetheless, the Gmail announcement does solve a major long-term problem. Here’s why: Gmail’s lack of support for the <style> tag has led to creation of tools called “inliners,” which effectively put the CSS code into the message itself. This adds bloat to the code of an email, because, instead of writing a line of CSS once and Gmail’s renderer repeating it every time a tag is referenced, it requires the specific CSS code to be embedded in every line.

<style>

Email developers have been inlining CSS code basically for the sake of Gmail.

According to Campaign Monitor, Gmail is the only mainstream client that doesn’t support this feature. As a result, email developers have been inlining CSS code basically for the sake of Gmail. And on the development end of things, it makes emails larger and more likely to break.

(To put this another way, it’s basically the opposite of what Google is doing with its AMP initiative.)

In an article on the change, Geoff Phillips and Justin Khoo of Email on Acid, an email troublehooting/testing firm, expressed genuine excitement—though they did note some specific areas where things remained unclear.

“This is huge,” they wrote in a blog post. “This means that we can stop using inline styles for every single thing in email. You can use a class instead, and a single update to that class in the head will affect every instance of that style. Like real web development.”

(It should be noted that Khoo probably deserves significant credit for Gmail’s changes—he prominently called out Google for their poor email standards support in a TechCrunch blog post last year.)

Regarding the media queries, Kevin Mandeville of marketing software company Litmus notes that designers previously had to use complex, hacky techniques to create an approach that did the same thing.

“Email designers, it’s time to say goodbye to these complicated layout structures,” Mandeville wrote. “But, keep in mind—you still need tables for Outlook. (We haven’t created an email standard … yet).”

How Can We Make Email Design Less Painful?

Gmail’s move doesn’t solve every problem that email designers have, but it could cut down on some of the more stressful challenges they face.

According to the Litmus 2016 State of Email Production report, nearly three-quarters of 900 survey respondents (73.3 percent) admitted to inlining CSS by hand, an incredibly arduous process.

(On the plus side, things are leaning in favor of more standards-friendly clients. Litmus Labs reports that the most popular email client is one with stellar CSS support—Apple’s iOS, which between the iPhone and iPad made up 44 percent of all email opens in August. So things are getting better.)

So with this problem likely to be out of the way after Gmail’s big update, how else could you improve your association’s email development workflow? Perhaps the next place to look is the framework: According to the Litmus study, more than a third of respondents (37.6 percent) don’t use an HTML framework to develop their emails, while 44.2 percent use an internally developed one.

Systems like Zurb’s Foundation for Emails could hold a lot of potential for email development shops. Foundation allows developers to hide complex table layouts via its Inky templating language. Additionally, Foundation supports Sass, a programming language meant to simplify CSS coding.

A couple of other ideas for improving your email development processes:

Create set templates for different types of objects you use in your messages—a two-column layout, for example, or a credits box—so you aren’t reinventing the wheel every time you build an email. This type of process, called modular design, is one way to limit email design headaches.

Use command-line automators. Email design is full of annoying processes that take a lot of time to do by hand. Suggestion? Program them so they’re done automatically. A couple ways to tackle this include using the command-line tool Grunt or relying on a static site generator that renders your emails based on a set design. The Foundation for Emails framework borrows heavily from both of these techniques.

These may be somewhat out of your comfort zone, but if you bring them into your comfort zone, you might be able to cut back on some the headaches of email design.

You may not control what Google or Microsoft do with their clients, but you certainly have control over your development process.

(That said, there’s always a chance that Microsoft could fix its CSS support in the next version of Outlook. We can dream, right?)

(iStock/Thinkstock)