Email began as a text-only, 1:1 method of communication in 1971, when it was conceived by Ray Tomlinson. Over the decades email has evolved, moving away from the text-only versions of early email to HTML. Pushing email into the future has been the email developers, using creative techniques within strict confines.
In that time, email developers created all types of “best practices” to help others get started with email coding, or to act as reminders for those in the trenches of what email developers can and can’t do.
We’re here today to remind email developers that best practices shouldn’t be seen as static. They change. What was best for email developers in the late 1990s no longer rings true in the mid-2010s.
Here are seven email development myths that have been around for ages, and why it’s time to finally put them to rest:
Before mobile phones and tablets became commonplace and email was solely a desktop application, best practice dictated that all emails should be no wider or narrower than 600 pixels. Why exactly 600 pixels? The viewport size of the most commonly used email clients back in the day (HoTMaiL, Yahoo, and Outlook) was around 500-550 pixels. Setting the email width to be no wider than 600 pixels would allow as little horizontal scrolling in the email as possible.
That 600 pixel rule stuck around. Even though today there are more devices to cater for, all with varying screen sizes, why do we stick to the this 600 pixel rule?
It’s an easy rule to stick by, especially if your email workflow includes creating a design in Adobe Photoshop or Sketch—you need a physical width to start your email design. It’s true that an email that is 600 pixels in width will still display very nicely among the more popular email clients, on desktops. And by using media queries, email developers can easily change the width of the email depending on the device subscribers use to open..
Fluid width solves the problem of the sheer number of devices email developers need to support. To make this work,use max-width to stop emails getting too wide and illegible on larger viewports, and MSO conditional statements to make Outlook understand (as it does not render the max-width CSS property).
Zalando’s emails are 450 pixels wide—a long way from the 600 pixel standard we’re used to seeing. Combined with the large CTAs, it looks like Zalando’s mobile-friendly emails cater more toward the mobile crowd.
Zalando’s emails are 450 pixels wide—a long way from the 600 pixel standard we’re used to seeing. Combined with the large CTAs, it looks like Zalando’s mobile-friendly emails cater more toward the mobile crowd.
MYTH #2: YOU MUST USE STANDARD SYSTEM FONTS ONLY.
System fonts have long been the safe option for use in email. Well, they’ve been the only option.
On the other hand, web designers have been experimenting with using non-standard fonts on the web since the early 2000s. In 2008, the CSS rule @font-face finally had the support from web browsers for web designers to use non-standard fonts on their websites. In 2010, Google launched its own library of web fonts, free for web designers to use.
No such luck for email designers due to the lack of a solid method for importing the web fonts into an HTML email. Not to mention the lack of licensing: when web fonts were first created, no one ever thought they’d be used in emails, so licensing of web fonts didn’t cover email use.
Though we recommend standard system fonts in your emails, that doesn’t mean you can’t employ web fonts as a progressive enhancement technique. Online font repositories are beginning to cover email use in their licensing. And Google Fonts, with its 800 free-to-use web fonts, is now becoming the go-to library for email designers wanting to use non-standard web fonts in their emails.
Support for web fonts exist in Google Android 4.4, Apple Mail for the iPhone, iPad and Mac, and Outlook 2011 and 2016 on OS X. This may not seem like a lot, but as of September this year four of the top five email clients, in market share, support web fonts–iPhone, iPad, Google Android, and Apple Mail. That’s over 50% of all email opens in September! Of course, you need to look at your own subscriber base, but this is a good indicator of potentially how many people will be able to see web fonts in your emails.
Can you see the subtle differences between these two emails? The one on the left is using web fonts, while the right one has web fonts disabled. The Outnet have chosen a great fallback font which is very close in look and feel to their web font, showing how you can use web fonts consistently in your email today.
MYTH #3: ONLY USE THE TRANSITIONAL DOCTYPE.
The DOCTYPE of an HTML document tells the browser how to render the page, and is used to validate the document’s HTML.
The most commonly used DOCTYPE in email is:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional //EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Email developers have gotten into the good habit of having a DOCTYPE, even though some email clients will strip the DOCTYPE altogether or replace it with a different one. Gmail, Outlook.com, and Yahoo! Mail are among the email clients that strip out whatever DOCTYPE present in your email, and replace it with HTML5 DOCTYPE.
On the web, different DOCTYPEs change how some CSS properties and HTML elements are rendered. The above DOCTYPE allows for the widest range of HTML elements, including deprecated elements like <font>, which have been used in email. In past tests, this DOCTYPE was proven to be the most reliable for email. WAS proven—past tense.
This was before HTML5 became the standard it is now:
<!DOCTYPE html>
The HTML5 DOCTYPE allows for the use of newer HTML5 elements, for example <video>, which can be used in email. While not all clients may be able to render the new elements or properties, there is no reason not to nudge your email into the future by updating your DOCTYPE. You can still used deprecated code with a HTML5 DOCTYPE, but the code will no longer be valid when checked through a validation service. While there’s no impact on your email in terms of deliverability or performance if your code is valid or not, it can be a good idea to check your HTML markup for open HTML tags, which can impact how your email is rendered.
MYTH #4: ATTRIBUTE SELECTORS NEED TO BE USED.
Yahoo! Mail has been a slightly kinder email client to develop for than, say, Outlook. It supported style in the head for as long as we can remember. One quirk Yahoo! Mail did offer up was that it rendered any CSS statement in a media query alongside any CSS outside of the media queries. The simple fix for this was to write the CSS statement as an attribute selector:
Writing CSS in the head of emails like this became the standard as other email clients, which also read style in the head, had no problem reading simple attribute selectors, like the example above.
However, because attribute selectors had been so ingrained in email development, it wasn’t surprising to see them still kicking around in email code. Email developers were simply used to using them, and often email templates went un-updated.
Previously harmless, attribute selectors can now do a little bit of harm to your email, if you do have them in your code. If your email’s style doesn’t appear to be working in Gmail, check to see if you’re still using attribute selectors in your style. Gmail does not support attribute selectors, but it does now (finally!) support style in the <head>.
With attribute selectors no longer required for Yahoo! Mail and Gmail’s lack of support for them, there is no need to use attribute selectors in the CSS in your emails.
MYTH #5: ALL STYLES IN EMAILS MUST BE INLINED.
Tables for layout and inlining styles have been the bedrock of email development since… forever. They define the difference between email and web development. Inlining styles is now so commonplace for email developers, it’s become a bit fuzzy on why styles had to be inlined in the first place.
SHOCKINGLY, SOME SITES CLAIM THAT THE REASON INLINE STYLES ARE NEEDED IS BECAUSE OF OUTLOOK AND GMAIL. WHICH IS JUST PLAIN WRONG. [TWEET THIS]
Outlook has never had a problem with style in the head of the email. On the other hand, Gmail did. Gmail has literally been the biggest reason (with a market share of 16% as of September 2016) as to why email developers inline their CSS.
At the end of September, Gmail began supporting style in the head. So do we need to inline all styles anymore?
If your subscribers mostly use Gmail, iOS, or even Outlook, we can confidently say now is the time to move your styles to the head. However, if the majority of your subscribers use obscure email clients or international email clients (Yandex, Libero, T-Online.de) that rely on inline styles, you may have to continue using them. As always we advocate testing your email whenever you make any major changes to it.
MYTH #6: DON’T USE BACKGROUND IMAGES IN EMAILS.
Background images have been notoriously hard to get right in email. Email developers use complicated VML code for them to render in many versions of Outlook, and there’s been a lack of support for background images in other email clients too.
Here’s the thing: background images can and do work in email, but it’s how they’re incorporated into the design of your email. With limited support, you shouldn’t use background images as a key element in your email’s design, because that makes or breaks the experience for your subscriber. But you can use them in your email similar to how you’d use web fonts—as a progressive enhancement.
We use background images in the header of this email to add depth to the email design, and fallback to a solid color for email clients that don’t support background images.
One of the biggest reasons for not using background images in email was Gmail’s lack of support for the CSS properties background-size and background-position. These CSS properties are important for high pixel density screens and hybrid/fluid/responsive email, where a certain amount of control needs to be placed on how the background images are sized and placed. Both are now supported in Gmail and Inbox by Gmail, so there’s even less of a reason to not try out using background images in email.
MYTH #7: EMAILS MUST LOOK IDENTICAL ACROSS ALL EMAIL CLIENTS.
Email clients all have slightly different ways of rendering HTML emails. Rather than accepting this, email developers have tried to hack their way to identical emails across a multitude of email clients. A very honorable task to undertake, but it can result in bloated and hacky HTML code which can be a nightmare to manage and keep up to date.
It might not be the email developer searching for email perfection, but the client or other stakeholders. However, it is the email developer’s responsibility to educate those around them to understand the pitfalls of email development—why email clients render differently and why it doesn’t matter if something’s 1 pixel higher in one email client compared to another.
This myth is especially harmful when trying to employ new techniques in email, which may not render across 100% of email clients, for example web fonts and background images. Both of which are fantastic ways to enhance your email. And where would we be as an industry if we didn’t try to adopt and experiment with new techniques in our emails?
Just because something has been done a particular way for years doesn’t mean there’s no better way to do it. Now is the time to question the rules and best practices the email marketing industry have been working with for decades.
CODE EMAILS FASTER–AND EASIER–WITH BUILDER
Speed up your email development workflow with Builder, the only code editor built specifically for email. And it’s free!
Loaded All PostsNot found any postsVIEW ALLReadmoreReplyCancel replyDeleteByHomePAGESPOSTSView AllRECOMMENDED FOR YOULABELARCHIVESEARCHALL POSTSNot found any post match with your requestBack HomeSundayMondayTuesdayWednesdayThursdayFridaySaturdaySunMonTueWedThuFriSatJanuaryFebruaryMarchAprilMayJuneJulyAugustSeptemberOctoberNovemberDecemberJanFebMarAprMayJunJulAugSepOctNovDecjust now1 minute ago$$1$$ minutes ago1 hour ago$$1$$ hours agoYesterday$$1$$ days ago$$1$$ weeks agomore than 5 weeks agoFollowersFollowTHIS CONTENT IS PREMIUMPlease share to unlockCopy All CodeSelect All CodeAll codes were copied to your clipboardCan not copy the codes / texts, please press [CTRL]+[C] (or CMD+C with Mac) to copy
COMMENTS