{"id":6021,"date":"2016-10-25T00:00:00","date_gmt":"2016-10-25T00:00:00","guid":{"rendered":"https:\/\/www.litmus.com\/blog\/7-myths-of-email-development\/"},"modified":"2023-07-13T12:23:24","modified_gmt":"2023-07-13T16:23:24","slug":"7-myths-of-email-development","status":"publish","type":"post","link":"https:\/\/www.litmus.com\/blog\/7-myths-of-email-development","title":{"rendered":"7 Myths of Email Development"},"content":{"rendered":"<p>Email began as a text-only, 1:1 method of communication in 1971, when it was conceived by <a rel=\"noopener\" href=\"https:\/\/litmus.com\/blog\/a-tribute-to-ray-tomlinson-the-inventor-of-modern-email-look-how-far-weve-come\">Ray Tomlinson<\/a>. 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.<\/p>\n<p>In that time, email developers created all types of \u201cbest practices\u201d 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\u2019t do.<\/p>\n<p>We\u2019re here today to remind email developers that best practices shouldn\u2019t be seen as static. They change. What was best for email developers in the late 1990s no longer rings true in the mid-2010s.<\/p>\n<p>Here are seven email development myths that have been around for ages, and why it\u2019s time to finally put them to rest:<\/p>\n<ul>\n<li><a rel=\"noopener\" href=\"#myth1\">Myth #1: Emails must be 600 pixels wide.<\/a><\/li>\n<li><a rel=\"noopener\" href=\"#myth2\">Myth #2: You must use standard system fonts only.<\/a><\/li>\n<li><a rel=\"noopener\" href=\"#myth3\">Myth #3: Only use the Transitional DOCTYPE.<\/a><\/li>\n<li><a rel=\"noopener\" href=\"#myth4\">Myth #4: Attribute selectors need to be used.<\/a><\/li>\n<li><a rel=\"noopener\" href=\"#myth5\">Myth #5: All styles in emails must be inlined.<\/a><\/li>\n<li><a rel=\"noopener\" href=\"#myth6\">Myth #6: Don\u2019t use background images in emails.<\/a><\/li>\n<li><a rel=\"noopener\" href=\"#myth7\">Myth #7: Emails must look identical across all email clients.<\/a><\/li>\n<\/ul>\n<h2 id=\"myth1\">Myth #1: Emails must be 600 pixels wide.<\/h2>\n<p>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.<\/p>\n<p>That 600 pixel rule stuck around. Even though today there are <a rel=\"noopener\" href=\"https:\/\/litmus.com\/blog\/understanding-responsive-and-hybrid-email-design\">more devices to cater for<\/a>, all with varying screen sizes, why do we stick to the this 600 pixel rule?<\/p>\n<p>It\u2019s an easy rule to stick by, especially if your <a rel=\"noopener\" href=\"https:\/\/litmus.com\/blog\/automate-email-development-workflow-webinar-recording\">email workflow<\/a> includes creating a design in Adobe Photoshop or Sketch\u2014you need a physical width to start your email design. It\u2019s 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..<\/p>\n<p>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 <a rel=\"noopener\" href=\"https:\/\/litmus.com\/blog\/mastering-outlook-a-look-back-at-common-rendering-issues\">Outlook<\/a> understand (as it does not render the max-width CSS property).<\/p>\n<figure id=\"post-15354 media-15354\" class=\"aligncenter nudged\"><img decoding=\"async\" src=\"https:\/\/www.litmus.com\/wp-content\/uploads\/2020\/04\/7myths-zalando-572x1000.jpg\" alt=\"Zalando\" \/><figcaption><a rel=\"noopener\" href=\"https:\/\/litmus.com\/scope\/cmk9ze3sifbp\">View the full email<\/a><\/figcaption><\/figure>\n<p>Zalando\u2019s emails are 450 pixels wide\u2014a long way from the 600 pixel standard we\u2019re used to seeing. Combined with the large CTAs, it looks like Zalando\u2019s mobile-friendly emails cater more toward the mobile crowd.<\/p>\n<figure id=\"post-15352 media-15352\" class=\"aligncenter nudged\"><img decoding=\"async\" src=\"https:\/\/www.litmus.com\/wp-content\/uploads\/2020\/04\/7myths-actionrocket-sizes-1000x451.jpg\" alt=\"Email Weekly\" \/><figcaption>Email Weekly&#8217;s responsive email at different widths. <a rel=\"noopener\" href=\"https:\/\/litmus.com\/scope\/o9fdocbl3el2\">View the full email<\/a><\/figcaption><\/figure>\n<p>Meanwhile, Email Weekly\u2019s emails employ the fluid technique, with a max-width of 960 pixels. It uses media queries to gracefully change the width of the email depending on the device width.<\/p>\n<p>Depending on the clients and devices your subscribers use to open your email, it can make sense to set your email\u2019s width to a maximum other than 600 pixels.<\/p>\n<div class=\"cta\">\n<table>\n<tbody>\n<tr>\n<td class=\"block-1\"><img decoding=\"async\" src=\"https:\/\/www.litmus.com\/wp-content\/uploads\/2020\/04\/tracking-manager.png\" \/><\/td>\n<td class=\"block-2\">\n<h2>Where are your subscribers opening your emails?<\/h2>\n<p>With Email Analytics you can find out which devices and emails clients they\u2019re opening your emails in.<\/p>\n<p class=\"zero\"><a class=\"btn medium orange button\" rel=\"noopener\" href=\"https:\/\/litmus.com\/email-analytics\" target=\"_blank\" rel=\"noopener noreferrer\">Learn more \u2192<\/a><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<h2 id=\"myth2\">Myth #2: You must use standard system fonts only.<\/h2>\n<p>System fonts have long been the safe option for use in email. Well, they\u2019ve been the only option.<\/p>\n<p>On the other hand, web designers have been experimenting with using non-standard fonts on the web since the <a rel=\"noopener\" target=\"_blank\" href=\"https:\/\/prowebtype.com\/history\/\">early 2000s<\/a>. 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 <a rel=\"noopener\" target=\"_blank\" href=\"https:\/\/fonts.google.com\/\">web fonts<\/a>, free for web designers to use.<\/p>\n<p>No such luck for email designers due to the lack of a solid method for importing the <a rel=\"noopener\" href=\"https:\/\/www.litmus.com\/blog\/the-ultimate-guide-to-web-fonts\/\">web fonts<\/a> into an HTML email. Not to mention the lack of licensing: when web fonts were first created, no one ever thought they\u2019d be used in emails, so licensing of web fonts didn\u2019t cover email use.<\/p>\n<p>Though we recommend standard system fonts in your emails, that doesn\u2019t mean you can\u2019t employ <a rel=\"noopener\" target=\"_blank\" href=\"https:\/\/www.campaignmonitor.com\/blog\/email-marketing\/2016\/07\/10-things-need-know-web-fonts-email-right-now\/\">web fonts as a progressive enhancement<\/a> 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.<\/p>\n<p>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 <a rel=\"noopener\" target=\"_blank\" href=\"https:\/\/emailclientmarketshare.com\">market share<\/a>, support web fonts\u2013iPhone, iPad, Google Android, and Apple Mail. That\u2019s 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.<\/p>\n<figure id=\"post-15353 media-15353\" class=\"aligncenter nudged\"><img decoding=\"async\" src=\"https:\/\/www.litmus.com\/wp-content\/uploads\/2020\/04\/7myths-webfont-1000x507.jpg\" alt=\"The Outnet\" \/><figcaption><a rel=\"noopener\" href=\"https:\/\/litmus.com\/scope\/jheil2s8tvwf\">View full email<\/a><\/figcaption><\/figure>\n<p>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.<\/p>\n<h2 id=\"myth3\">Myth #3: Only use the Transitional DOCTYPE.<\/h2>\n<p>The DOCTYPE of an HTML document tells the browser how to render the page, and is used to validate the document\u2019s HTML.<\/p>\n<p>The most commonly used DOCTYPE in email is:<\/p>\n<pre><code style=\"background: #444;color: #fff\">&lt;!DOCTYPE html PUBLIC \"-\/\/W3C\/\/DTD XHTML 1.0 Transitional \/\/EN\" \"http:\/\/www.w3.org\/TR\/xhtml1\/DTD\/xhtml1-transitional.dtd\"&gt;<\/code><\/pre>\n<p>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.<\/p>\n<p>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 &lt;font&gt;, which have been used in email. In past tests, this DOCTYPE was proven to be the most reliable for email. WAS proven\u2014past tense.<\/p>\n<p>This was before HTML5 became the standard it is now:<\/p>\n<pre><code style=\"background: #444;color: #fff\">&lt;!DOCTYPE html&gt;<\/code><\/pre>\n<p>The HTML5 DOCTYPE allows for the use of newer HTML5 elements, for example &lt;video&gt;, 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\u2019s 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.<\/p>\n<h2 id=\"myth4\">Myth #4: Attribute selectors need to be used.<\/h2>\n<p>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 <a rel=\"noopener\" target=\"_blank\" href=\"http:\/\/freshinbox.com\/articles\/yahoo-sanitizer-bug.html\">alongside any CSS outside<\/a> of the <a rel=\"noopener\" href=\"https:\/\/www.litmus.com\/blog\/understanding-media-queries-in-html-email\/\">media queries<\/a>. The simple fix for this was to write the CSS statement as an attribute selector:<\/p>\n<pre><code style=\"background: #444;color: #fff\">*[class=\u201dfoo\u201d] {color:#000000; font-family: sans-serif;}<\/code><\/pre>\n<p>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.<\/p>\n<p>In early 2015, <a rel=\"noopener\" target=\"_blank\" href=\"http:\/\/freshinbox.com\/blog\/yahoo-mail-fixes-media-query-bug-yahoo\/\">Yahoo! Mail rolled out an update<\/a> which enabled it to read style like any \u201cnormal\u201d email client would:<\/p>\n<pre><code style=\"background: #444;color: #fff\">.foo {color:#000000; font-family: sans-serif;}<\/code><\/pre>\n<p>However, because attribute selectors had been so ingrained in email development, it wasn\u2019t 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.<\/p>\n<p>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\u2019s style doesn\u2019t appear to be working in Gmail, check to see if you\u2019re still using attribute selectors in your style. Gmail does not support attribute selectors, but it does now (finally!) <a rel=\"noopener\" href=\"https:\/\/litmus.com\/blog\/gmail-to-support-responsive-email-design\">support style in the &lt;head&gt;<\/a>.<\/p>\n<p>With attribute selectors no longer required for Yahoo! Mail and Gmail\u2019s lack of support for them, there is no need to use attribute selectors in the CSS in your emails.<\/p>\n<h2 id=\"myth5\">Myth #5: All styles in emails must be inlined.<\/h2>\n<p>Tables for layout and inlining styles have been the bedrock of email development since\u2026 forever. They define the difference between email and web development. Inlining styles is now so commonplace for email developers, it\u2019s become a bit fuzzy on why styles had to be inlined in the first place.<\/p>\n<blockquote><p>Shockingly, some sites claim that the reason inline styles are needed is because of Outlook and Gmail. Which is just plain wrong. <a rel=\"noopener\" target=\"_blank\" href=\"http:\/\/ctt.ec\/7Z6za\" target=\"_blank\" rel=\"noopener noreferrer\">[Tweet this]<\/a><\/p><\/blockquote>\n<p>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 <a rel=\"noopener\" target=\"_blank\" href=\"https:\/\/emailclientmarketshare.com\/\">market share of 16%<\/a> as of September 2016) as to why email developers inline their CSS.<\/p>\n<p>At the end of September, Gmail began supporting style in the head. So do we need to inline all styles anymore?<\/p>\n<p>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, Terra) that rely on inline styles, you may have to continue using them. As always we advocate <a rel=\"noopener\" href=\"https:\/\/litmus.com\/blog\/have-you-tested-your-template-recently-heres-8-reasons-why-you-should\">testing your email<\/a> whenever you make any major changes to it.<\/p>\n<h2 id=\"myth6\">Myth #6: Don\u2019t use background images in emails.<\/h2>\n<p>Background images have been notoriously hard to get right in email. Email developers use complicated <a rel=\"noopener\" target=\"_blank\" href=\"https:\/\/www.backgrounds.cm\/\">VML code<\/a> for them to render in many versions of Outlook, and there\u2019s been a lack of support for background images in other email clients too.<\/p>\n<p>Here\u2019s the thing: background images can and do work in email, but it\u2019s how they\u2019re incorporated into the design of your email. With limited support, you shouldn\u2019t use background images as a key element in your email\u2019s design, because that makes or breaks the experience for your subscriber. But you can use them in your email similar to how you\u2019d use web fonts\u2014as a progressive enhancement.<\/p>\n<figure id=\"post-15361 media-15361\" class=\"aligncenter nudged\"><img decoding=\"async\" src=\"https:\/\/www.litmus.com\/wp-content\/uploads\/2020\/04\/7myths-bg.jpg\" alt=\"Background images\" \/><figcaption>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&#8217;t support background images.<\/figcaption><\/figure>\n<p>One of the biggest reasons for not using background images in email was Gmail\u2019s 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 <a rel=\"noopener\" href=\"https:\/\/litmus.com\/blog\/gmail-to-support-responsive-email-design\">Gmail and Inbox by Gmail<\/a>, so there\u2019s even less of a reason to not try out using background images in email.<\/p>\n<p><a rel=\"noopener\" target=\"_blank\" href=\"https:\/\/www.twitter.com\/joon82\">Kristian Robinson<\/a>, Lead Email Developer at TWO Digital marketing, and <a rel=\"noopener\" href=\"https:\/\/litmus.com\/blog\/the-email-design-conference-2016-heres-what-we-learned-in-london\">The Email Design Conference 2016<\/a> speaker, digs deeper into background images in email, if you\u2019re feeling inspired to tackle them.<\/p>\n<h2 id=\"myth7\">Myth #7: Emails must look identical across all email clients.<\/h2>\n<p>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.<\/p>\n<p>It might not be the email developer searching for email perfection, but the client or other stakeholders. However, it is the email developer\u2019s responsibility to educate those around them to understand the pitfalls of email development\u2014why email clients render differently and why it doesn\u2019t matter if something\u2019s 1 pixel higher in one email client compared to another.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">&quot;The time when emails had to be pixel-perfect is way behind us.&quot; @ericlepetitsf <a rel=\"noopener\" target=\"_blank\" href=\"https:\/\/twitter.com\/hashtag\/LitmusLive?src=hash&amp;ref_src=twsrc%5Etfw\">#LitmusLive<\/a><\/p>\n<p>&mdash; Chad S. White (@chadswhite) <a rel=\"noopener\" target=\"_blank\" href=\"https:\/\/twitter.com\/chadswhite\/status\/765606221768458240?ref_src=twsrc%5Etfw\">August 16, 2016<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>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\u2019t try to adopt and experiment with new techniques in our emails?<\/p>\n<p>Just because something has been done a particular way for years doesn\u2019t mean there\u2019s 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.<\/p>\n<h2>Code emails faster\u2013and easier\u2013with Builder<\/h2>\n<p>Speed up your email development workflow with Builder, the only code editor built specifically for email. And it\u2019s free!<\/p>\n<p><a class=\"btn orange medium\" style=\"color: #fff;font-weight: bold;font-size: 16px\" rel=\"noopener\" href=\"https:\/\/litmus.com\/builder\">Start using Builder \u2192<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Over the years email developers created all types of \u201cbest practices\u201d 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\u2019t do. But those have changed, and keep changing. Here are seven email development myths that have been around for ages, and why it\u2019s time to finally put them to rest.<\/p>\n","protected":false},"author":3,"featured_media":6023,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"tags":[478,9805],"blog_category":[57],"class_list":["post-6021","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","tag-design","tag-text","blog_category-observations"],"yoast_head":"<!-- This site is optimized with the Yoast SEO Premium plugin v27.5 (Yoast SEO v27.7) - https:\/\/yoast.com\/product\/yoast-seo-premium-wordpress\/ -->\n<title>7 Myths of Email Development - Litmus<\/title>\n<meta name=\"description\" content=\"Over the years email developers created all types of \u201cbest practices\u201d 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\u2019t do. But those have changed, and keep changing. Here are seven email development myths that have been around for ages, and why it\u2019s time to finally put them to rest.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.litmus.com\/blog\/7-myths-of-email-development\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"7 Myths of Email Development\" \/>\n<meta property=\"og:description\" content=\"Over the years email developers created all types of \u201cbest practices\u201d 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\u2019t do. But those have changed, and keep changing. Here are seven email development myths that have been around for ages, and why it\u2019s time to finally put them to rest.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.litmus.com\/blog\/7-myths-of-email-development\" \/>\n<meta property=\"og:site_name\" content=\"Litmus\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/litmusapp\" \/>\n<meta property=\"article:published_time\" content=\"2016-10-25T00:00:00+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2023-07-13T16:23:24+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.litmus.com\/wp-content\/uploads\/2020\/04\/featured-7-email-development-myths.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1380\" \/>\n\t<meta property=\"og:image:height\" content=\"724\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@litmusapp\" \/>\n<meta name=\"twitter:site\" content=\"@litmusapp\" \/>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"7 Myths of Email Development - Litmus","description":"Over the years email developers created all types of \u201cbest practices\u201d 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\u2019t do. But those have changed, and keep changing. Here are seven email development myths that have been around for ages, and why it\u2019s time to finally put them to rest.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.litmus.com\/blog\/7-myths-of-email-development","og_locale":"en_US","og_type":"article","og_title":"7 Myths of Email Development","og_description":"Over the years email developers created all types of \u201cbest practices\u201d 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\u2019t do. But those have changed, and keep changing. Here are seven email development myths that have been around for ages, and why it\u2019s time to finally put them to rest.","og_url":"https:\/\/www.litmus.com\/blog\/7-myths-of-email-development","og_site_name":"Litmus","article_publisher":"https:\/\/www.facebook.com\/litmusapp","article_published_time":"2016-10-25T00:00:00+00:00","article_modified_time":"2023-07-13T16:23:24+00:00","og_image":[{"width":1380,"height":724,"url":"https:\/\/www.litmus.com\/wp-content\/uploads\/2020\/04\/featured-7-email-development-myths.png","type":"image\/png"}],"twitter_card":"summary_large_image","twitter_creator":"@litmusapp","twitter_site":"@litmusapp","schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.litmus.com\/blog\/7-myths-of-email-development#article","isPartOf":{"@id":"https:\/\/www.litmus.com\/blog\/7-myths-of-email-development"},"author":{"name":"","@id":""},"headline":"7 Myths of Email Development","datePublished":"2016-10-25T00:00:00+00:00","dateModified":"2023-07-13T16:23:24+00:00","mainEntityOfPage":{"@id":"https:\/\/www.litmus.com\/blog\/7-myths-of-email-development"},"wordCount":2240,"commentCount":0,"publisher":{"@id":"https:\/\/www.litmus.com\/#organization"},"image":{"@id":"https:\/\/www.litmus.com\/blog\/7-myths-of-email-development#primaryimage"},"thumbnailUrl":"https:\/\/www.litmus.com\/wp-content\/uploads\/2020\/04\/featured-7-email-development-myths.png","keywords":["Design","Text"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.litmus.com\/blog\/7-myths-of-email-development#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.litmus.com\/blog\/7-myths-of-email-development","url":"https:\/\/www.litmus.com\/blog\/7-myths-of-email-development","name":"7 Myths of Email Development - Litmus","isPartOf":{"@id":"https:\/\/www.litmus.com\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.litmus.com\/blog\/7-myths-of-email-development#primaryimage"},"image":{"@id":"https:\/\/www.litmus.com\/blog\/7-myths-of-email-development#primaryimage"},"thumbnailUrl":"https:\/\/www.litmus.com\/wp-content\/uploads\/2020\/04\/featured-7-email-development-myths.png","datePublished":"2016-10-25T00:00:00+00:00","dateModified":"2023-07-13T16:23:24+00:00","description":"Over the years email developers created all types of \u201cbest practices\u201d 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\u2019t do. But those have changed, and keep changing. Here are seven email development myths that have been around for ages, and why it\u2019s time to finally put them to rest.","breadcrumb":{"@id":"https:\/\/www.litmus.com\/blog\/7-myths-of-email-development#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.litmus.com\/blog\/7-myths-of-email-development"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.litmus.com\/blog\/7-myths-of-email-development#primaryimage","url":"https:\/\/www.litmus.com\/wp-content\/uploads\/2020\/04\/featured-7-email-development-myths.png","contentUrl":"https:\/\/www.litmus.com\/wp-content\/uploads\/2020\/04\/featured-7-email-development-myths.png","width":1380,"height":724},{"@type":"BreadcrumbList","@id":"https:\/\/www.litmus.com\/blog\/7-myths-of-email-development#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.litmus.com\/"},{"@type":"ListItem","position":2,"name":"7 Myths of Email Development"}]},{"@type":"WebSite","@id":"https:\/\/www.litmus.com\/#website","url":"https:\/\/www.litmus.com\/","name":"Litmus","description":"Are you getting the most out of your email marketing?","publisher":{"@id":"https:\/\/www.litmus.com\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.litmus.com\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.litmus.com\/#organization","name":"Litmus Software","url":"https:\/\/www.litmus.com\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.litmus.com\/#\/schema\/logo\/image\/","url":"https:\/\/www.litmus.com\/wp-content\/uploads\/2025\/04\/featured-image.png","contentUrl":"https:\/\/www.litmus.com\/wp-content\/uploads\/2025\/04\/featured-image.png","width":600,"height":314,"caption":"Litmus Software"},"image":{"@id":"https:\/\/www.litmus.com\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/litmusapp","https:\/\/x.com\/litmusapp"]},{"@type":"Person","@id":""}]}},"acf":[],"_links":{"self":[{"href":"https:\/\/www.litmus.com\/wp-json\/wp\/v2\/posts\/6021","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.litmus.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.litmus.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.litmus.com\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.litmus.com\/wp-json\/wp\/v2\/comments?post=6021"}],"version-history":[{"count":2,"href":"https:\/\/www.litmus.com\/wp-json\/wp\/v2\/posts\/6021\/revisions"}],"predecessor-version":[{"id":73630,"href":"https:\/\/www.litmus.com\/wp-json\/wp\/v2\/posts\/6021\/revisions\/73630"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.litmus.com\/wp-json\/wp\/v2\/media\/6023"}],"wp:attachment":[{"href":"https:\/\/www.litmus.com\/wp-json\/wp\/v2\/media?parent=6021"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.litmus.com\/wp-json\/wp\/v2\/tags?post=6021"},{"taxonomy":"blog_category","embeddable":true,"href":"https:\/\/www.litmus.com\/wp-json\/wp\/v2\/blog_category?post=6021"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}