JRDo you think we’ll ever have standards for coding emails?
So, I know this debate comes up every now and then, but I still think it’s a good one to have.
Do you think we’ll ever have standards for coding emails?
There have been various movements in the past to get email client developers to support a standard level of HTML and CSS, allowing designers to build campaigns more consistently and efficiently, but nothing’s come of them, yet.
Is it just a pipe dream to expect vendors to get on board similar to how they did with web standards? More importantly:
- What’s holding them back?
- What would an email standard look like?
- And is there anything we can do to bring about change?
We've also got an interesting post on the topic over on our blog. Check it out and weigh in on the conversation.
My own take is that we’re not likely to see a standard anytime soon (if ever). A large percentage of email clients are essentially legacy apps that no one is willing to significantly update. And while we are all clamoring for better code support, most consumers haven’t even thought about the issue. Vendors are in the business of pleasing users, not marketers, so until those users get sufficiently fed up with terrible looking emails, they don’t have any real motivation to change anything.
We do not we need standard coding for emails per se. We need standard rules for email preprocessing (and the ability to override default styles). If every vendor processed email the same way we would not have this problem. We would know exactly how vendors treat our code, what tags are not allowed, what css is not allowed. Then the discussion could turn towards what code is or isn't allowed. The reason preprocessors exist is so that code we send does not conflict with rendering in mail clients, and so that unsafe code is removed to protect users from malicious attacks.
As for what this would look like? I believe a simple whitelist of tags, attributes and styles would suffice. HTML5/CSS3/Media query support would be a nice bonus but not absolutely necessary. We would then only need to worry about the browser's rendering engine to ensure nothing breaks.
For this to work the Word rendering engine has got to go. I don't think that's going to happen unless we start doing things like this:
How do you engage Apple, Google, Microsoft, Mozilla and Yahoo for such a thing? Mind you there are dozens if not hundreds of other email vendors out there. Convince the market leaders and the rest will follow? Do we write our own preprocessor and market it to them one at a time? Write our own mail app and take over the world?
Yeah, the project for creating these standards is still ongoing. The bigger question is around wether they'll bother to put any resource behind changing the systems that are in place. It's probably a non-trivial issue for Gmail, so it'd need to be justified in monetary terms.
Definitely agree on your points, except the last one about starting to do 'get a better client' messages in emails.
I feel like that's almost laying fault on the user for how emails display. And, while it might get a few people to switch to something else, the vast majority won't for various reasons. Lots of people use email clients out of necessity, not out of desire, so calling them out on their client is unnecessarily antagonistic. I'd much prefer to keep working within the constraints we currently do and make the experience as solid as possible for subscribers, while trying to work with vendors to improve things (however unlikely that is to happen).
Barring that, I say we all just band together and build the best email client ever. As part of the terms of an inevitable acquisition, require any company to support HTML and CSS going forward :-)
I agree with Michael that the goal isn't standards but consistency. Its problematic for webmail to support certain kinds of CSS such as absolute positioning - so there will be a gap between native and web based clients at least for the near future. The issue is that even among similar clients, they can't agree on which CSS to support.
I think the community can definitely do its part to make them aware that inconsistent CSS support = broken email = bad UX for their users.
Ultimately what I think will move their hand is when the email clients start supporting the creation of "advanced emails" and feeling the angst first hand. For example Yahoo! Mail allows the creation of event invites and image galleries - but these layouts actually look broken in Outlook. Once they add more and more of these features they'll be motivated to work together to get this fixed.
I think you've hit the nail on the head when you say " Vendors are in the business of pleasing users, not marketers". That's crucial and the reason for this is that Vendors have no stake in making sure promo emails are delivered.
To get to some solid standards, we'd need a paradigm shift whereby email is treated like any other marketing channel. We'd pay a fee to send to our audience, but for that fee, we'd get better deliverability, proper analytics and most importantly, Vendors would have an interest in keep advertisers happy.
There are good reasons why vendors haven't done this, it'd be a bad strategic move for Gmail, for instance, to get involved in making sure promotions turn up in the inbox, (plus they already kind of have a platform for this kind of thing)
Will we ever have email coding standards? This is a tricky question and my views on the matter have definitely evolved over the years along with the evolution of the email client and device landscape. Let me start by saying I now think there will never be a single email coding standard.
However, that’s doesn’t mean that we’re doomed to our current highly fragmented existence. In the future, there will likely be a patchwork of common and independent rendering engines. The future of email will still be fragmented, but there will be significant areas of consolidation.
Mark Robbins of Rebelmail is right that we need a standard rendering engine, otherwise we’ll be fighting the same fight for standardization every time a major email client releases a new version. Thankfully ISPs have financial and logistical reasons to want to standardize around rendering engines as well.
This is most likely to occur first within the webmail environment, where market share is declining. This will put financial pressure on ISPs, and standardizing on a common rendering engine will be seen as a sensible solution for many ISPs.
The mobile environment, which is still growing nicely, won’t be subject to such pressures, so multiple rendering engines will continue to exist there. That said, the companies that rule most of mobile—namely, Apple and Google—will likely eventually consolidate their own mobile operations around single rendering engines to streamline development efforts. It’s just bad business for Google, for instance, to operate some many different email rendering engines. But the key word here is “eventually.”
And then there’s wearables and the internet of things. This is where things will only get messier and messier. Watches, e-readers, electronic paper, and other devices will dumb email down to plain text (perhaps HTML text at some point, if we’re lucky). Ear fobs, automobiles, etc. will read emails to us, and our replies and actions will be verbalized.
Oh, and the desktop environment (aka Microsoft Outlook) will also continue to be a mess, but it will continue to lose market share to cloud-based solutions, chiefly Google’s Gmail. And eventually—perhaps five years from now—on-premise email will be isolated to markets that only a small percentage of marketers will need to concern themselves with.
So basically, the future of email rendering is stratified, with the rending layers varying from standardized (i.e., webmail) to consolidated (i.e., mobile app mail) to, let’s say, untamed (i.e., wearables, Iot, desktop). On net, this should make the job of email designers and developers a bit easier, but only a bit.
I am vaguely aware of the long and drawn-out processes behind HTML's updates over the years (such as how HTML5 was developed). Why has the road to HTML standards been so different from the (non)road to e-mail standards? That is to say, how did we wind up in a place where the controllers of e-mail clients became like gods on a pedestal who can't be approached by groups of coders working on an e-mail standard? (is it because e-mail clients never started out open-source?)
It seems strange, particularly because e-mail is older than the web itself. The geek in me would love to read a concise history of how we got from there to here.
Very much share your thoughts, Jason. It is a user market. From a user POV, Gmail does a really good job with its interface, sorting emails, being able to find things easily. As an email client, I haven't been able to find something I like as much as a user. Yes, it's terrible at rendering, but aside from marketers, are the every day end users who make up the majority of their user base interested in that?
I'm a bit pessimistic about their being a universal email rendering standard, because it'll have to be created as a new entity. I'm still seeing customers open emails using Outlook 2007 and 2010. There's no way you can force them to change. And most don't have the ability as they'll like to be viewing emails at work, on work computers, where they simply don't have a say.
Hi Jason and fellow Email enthusiasts and experts,
This issue can and will only ever be resolved if the standards we seek are [well] documented.
Please join me in the W3C HTML for Email Community Group, where we can create and propose an actual specification.
Please also see this discussion.
Invitations are being made to responsible parties from major email vendors.