Email quirks and bugs
A repository for documenting bugs in webmails and email applications, inspired by Device Bugs and SVG Weirdness.
The goal is to make email designers life easier in order to find and understand weird email clients behaviors. But it's also to try to improve the situation by reporting each bug to the concerned company.
Here is where to report bugs for the following clients :
In its desktop webmail, AOL incorrectly prefixes every step inside a @keyframes declaration by . aolReplacedBody. The following example…
<style type="text/css">
@keyframes background900
{
0% { background-position:0 0; }
100% { background-position:0 -900px; }
}
</style>
<div style="width:480px; height:480px; background:#000 url(http://i.imgur.com/WItksSm.png) repeat-y; animation:background900 45s linear infinite;"></div>… is transformed by AOL into :
<style type="text/css">
@keyframes background900
{
. aolReplacedBody 0% { background-position:0 0; }
. aolReplacedBody 100% { background-position:0 -900px; }
}
</style>
<div style="width:480px; height:480px; background:#000 url(http://i.imgur.com/WItksSm.png) repeat-y; animation:background900 45s linear infinite;"></div>This is incorrect in CSS, and makes the animation void. Steps inside a @keyframes declaration should not be prefixed.
Hello there!
I've tested the double <style> with @media query for a mobile devices.
It seems that most of them don't respect it, which is interesting - even these which actually support responsive layout.
https://litmus.com/pub/f69ebc6
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office">
<head>
<!--[if gte mso 9]>
<xml>
<o:OfficeDocumentSettings>
<o:AllowPNG/>
<o:PixelsPerInch>96</o:PixelsPerInch>
</o:OfficeDocumentSettings>
</xml>
<![endif]-->
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1" />
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<meta name="format-detection" content="date=no" />
<meta name="format-detection" content="address=no" />
<meta name="format-detection" content="telephone=no" />
<title>Email </title>
<style type="text/css" media="all">
@media only screen and (max-device-width: 480px), only screen and (max-width: 480px) {
.h1-center { color: #fff000 !important; }
}
</style>
</head>
<body class="body" style="padding:0 !important; margin:0 !important; display:block !important; min-width:100% !important; width:100% !important; background:#000001; -webkit-text-size-adjust:none;">
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="td" style="width:600px; min-width:600px; font-size:0pt; line-height:0pt; padding:0; margin:0; font-weight:normal;">
<style type="text/css" media="all">
@media only screen and (max-device-width: 480px), only screen and (max-width: 480px) {
.h1-center { color: #ff0000 !important; }
}
</style>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="h1-center" style="padding-bottom: 20px; color:#ffffff; font-family:Arial,sans-serif; font-size:16px; line-height:20px; text-align:center;">
<strong>
LOVE 'EM (LIKELY).<br />
HATE 'EM (NEVER).
</strong>
</td>
</tr>
</table>
</td>
</tr>
</table>
</body>
</html>
Would anyone help me with ideas - How to make that second <style> be respected for mobile?
Thank you,
Stojjan
For historical purposes and future references, I'm archiving here an old Yahoo bug. Up until March 2015, the desktop webmail of Yahoo didn't support media queries. But Yahoo incorrectly filtered media queries, removing anything between the first opening accolade of a media query and the first closing accolade of the first rule inside the media query. It thus leave other styles in the media query applicable for any media.
Here's an example. Given the following code:
.box {
width:600px;
}
@media only screen and (max-width:600px) {
.box {
width:auto;
}
.box-title {
font-size:1.25em;
}
}Yahoo would filter it like this:
#yiv6851014585 .yiv6851014585box {
width:600px;
}
_filtered #yiv6851014585 {
}
#yiv6851014585 .yiv6851014585box-title {
font-size:1.25em;
}
}(Notice how the rule .box-title is now outside of a media query and thus applicable anywhere.)
A solution widely shared was to use attributes selectors in CSS instead (like [class="box"] instead of .box`). The desktop webmail of Yahoo didn't support them either, thus filtering them and not applying them anywhere.
The following example…
.box {
width:600px;
}
@media only screen and (max-width:600px) {
*[class="box"] {
width:auto;
}
*[class="box-title"] {
font-size:1.25em;
}
}…would be filtered by Yahoo into:
#yiv6851014585 .yiv6851014585box {
width:600px;
}
_filtered #yiv6851014585 {
}
#yiv6851014585 * .filtered99999 {
font-size:1.25em;
}
}This was also widely documented and fixed thanks to Fresh Inbox who documented and reported the bug at the time.
Using double quotes in a CSS selector completely messes up with AOL desktop webmail's parser. The following example…
[class="test"] { color:red; }… becomes :
.aolReplacedBody [class="
test"
] {
color: red;
}It gets even worse when combined with a pseudo class and multiple selectors for a same rule set. The following…
.test:hover, [class="test"]:hover { color:red; }…becomes :
test"
]:hover {
color: red;
.aolReplacedBody .test: hover,.aolReplacedBody [class="
}This is an example of responsive table layout
<table width="100%">
<tr>
<th style="font-size: 0; padding: 0;"> </th>
<th width="600" style="padding: 0;">
<!-- content -->
</th>
<th style="font-size: 0; padding: 0;"> </th>
</tr>
</table>For correct responsibility we should use viewport
<meta name="viewport" content="width=device-width, initial-scale=1.0">Screenshot with example of the problem
Source code of email from screenshot https://gist.github.com/dudeonthehorse/77e33aa3a1797883b88a6eb11c969b72
Outlook.com and Office 365 remove styles that include special characters, like =, * or /. Here is an example that is correctly filtered. The following code…
<div style="background:#3cbc67; foo:bar; font-size:32px;">foo</div>…is transformed by Outlook.com into :
<div style="background:#3cbc67; font-size:32px;">foo</div>The following code, however…
<div style="background:#3cbc67; foo:=; font-size:32px;">foo</div>…is transformed by Outlook.com into :
<div style="">foo</div>I noted the following characters could cause this bug : =, *, /, $, %, \, &, @, ^, {, }, [, ], (, ), ?, |, <, >, ```. These look like characters usually found in regular expressions.
This means properties like filter: alpha(opacity=50); would make the whole inline style attribute they're in disappear.
Here is a test email used for this bug.
This bug was discussed on Litmus forums here.
Outlook.com usually prefixes classes and ids used in HTML by ecx. It then adjust selectors used in a <style> tag accordingly (prefixing every rule by a .ExternalClass class). However, for certain names, the prefixing doesn't work in HTML, but happens in CSS, thus creating inoperative rules. I've noticed this happens with the following names :
So for example if we have the following code :
<style type="text/css">
.test,
#test,
.button,
.menu,
.label,
.nav,
#button,
#menu,
#label,
#nav {
padding:1em 1.5em;
color:#fff;
background:#2ecc40;
}
</style>
<div class="test">.test</div>
<div id="test">#test</div>
<div class="button">.button</div>
<div id="button">#button</div>
<div class="menu">.menu</div>
<div id="menu">#menu</div>
<div class="label">.label</div>
<div id="label">#label</div>
<div class="nav">.nav</div>
<div id="nav">#nav</div>… will be transformed by Outlook.com into this :
<style type="text/css">
.ExternalClass .ecxtest,
.ExternalClass #ecxtest,
.ExternalClass .ecxbutton,
.ExternalClass .ecxmenu,
.ExternalClass .ecxlabel,
.ExternalClass .ecxnav,
.ExternalClass #ecxbutton,
.ExternalClass #ecxmenu,
.ExternalClass #ecxlabel,
.ExternalClass #ecxnav {
padding:1em 1.5em;
color:#fff;
background:#2ecc40;
}
</style>
<div class="ecxtest">.test</div>
<div id="ecxtest">#test</div>
<div class="button">.button</div>
<div id="button">#button</div>
<div class="menu">.menu</div>
<div id="menu">#menu</div>
<div class="label">.label</div>
<div id="label">#label</div>
<div class="nav">.nav</div>
<div id="nav">#nav</div>This happens in Outlook.com on both the desktop and mobile webmail versions.
Hello, Remi!
I know about Nicole Merlin method. I know about "Fab Four". It's cool practices. I use it in my projects.
But... What do you think about this example?
https://jsfiddle.net/xq6cptwd/
<table align="center" style="border-collapse: collapse; border-spacing: 0;" border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr align="center">
<td></td>
<td bgcolor="#D7EFFE" width="128" align="center" style="display: inline-block;">
Alexey
</td>
<td bgcolor="#D7EFFE" width="128" align="center" style="display: inline-block;">
Marie
</td>
<td bgcolor="#D7EFFE" width="128" align="center" style="display: inline-block;">
Sergey
</td>
<td bgcolor="#D7EFFE" width="128" align="center" style="display: inline-block;">
Vadim
</td>
<td></td>
</tr>
</tbody>
</table>
That's how we can use fluid method with supporting lotus notes client, for example
In the first beta of iOS 10, Apple Mail has a new mechanism that doesn't always auto-scale non responsive emails. This results in huge emails that needs to be scrolled horizontally and vertically, and what I think is a poorer experience. But this mechanism doesn't seem consistent. Sometimes, non responsive emails will auto-scale. And other times, they won't. The aim of this issue is to list examples of emails that don't auto-scale, and try to find fixes and understand what causes the non auto-scale in iOS 10.
Here are two examples reported on Twitter by Alex Williams and Eric Lepetit.
When you use a decimal point in an animation, AOL thinks it’s a class name and it’ll get prefixed with aolmail_ so 33.33% becomes 33.aolmail_33%.
Here's a simple test file I sent
https://gist.github.com/M-J-Robbins/580b1afeb4c6e223aef5511c289f3ea9
And here it is as rendered in AOL mail
https://gist.github.com/M-J-Robbins/e87718699957acb59fdd3cbbb5999081
Note the issue appears on lines 15 and 18
I've tested decimal points in other places such as width:33.33%; font-size:1.5em and they seem to render fine.
The desktop webmail of Orange.fr incorrectly prefixes CSS comments in a <style> tag, making a following @media declaration invalid.
The following styles…
<style type="text/css">
/* Hello world */
@media {
.foo { background:red; }
}
</style>… are transformed by Orange into the following:
<style type="text/css">
#message
@media {
.foo { background:red; }
}
</style>The media query is turned into #message @media, which doesn't make sense in CSS and is thus ignored.
In general, I think it's a good practice to avoid leaving CSS comments in an email. Yahoo has a very similar bug with CSS comments.
The desktop webmail of SFR has annoying default styles applying to <a> tags inside <th>. It adds a grey background, sets the color in white and adds a right padding of 20px. Here are the incriminating styles:
th a, th a:link, th a:visited {
color: #fff;
background: #808080;
padding-right: 20px;
}The styles can be found in SFR's main.css file. Here's an example shared by someone (sorry I can't remember who) last october on the #emailgeeks slack.
These default styles can be reset within an HTML email by including the following styles:
th a, th a:link, th a:visited {
color: initial;
background: initial;
padding-right: initial;
}The mainstream desktop webmail of Gmail removes <style> tags that contain an @ declaration within an @ declaration.
The following code…
<html>
<head>
<style>
p { background:#e4505d !important; }
</style>
<style>
p { background:#3cbc67 !important; }
@media only screen and (max-width:320px) {
@viewport { width:320px; }
}
</style>
<style>
p { background:#3cbc67 !important; }
@ { @ }
</style>
</head>
<body>
<p style="color:#fff; background:#000;">
Lorem ipsum dolor sit amet, consectetur adipisicing elit.
</p>
</body>
</html>…is transformed by Gmail into the following :
<html>
<head>
<style>
p { background:#e4505d !important; }
</style>
</head>
<body>
<p style="color:#fff; background:#000;">
Lorem ipsum dolor sit amet, consectetur adipisicing elit.
</p>
</body>
</html>I use nunjucks template engine with my email builder. Markdown is a great tool to make content newsletters.
This is the list of email-safe markdown elements to use:
<h1>-<h4> — really no need more than 4 levels of headings. This elements needs for maximum styling to prevent specific email-client css<ul> and <ol> — we must be careful with horizontal paddings (for normal buiilts rendering)<strong>, <em> — but I'm not sure about font-style: normal for em. Will it works correct in all clients?Not safe elements to use in emails:
<hr> — but we can use it with Inky(or another component library) for converting syntax to safe<blockquote> — Yandex Mail hides <blockquote> contents under dropdown spoiler<table> — I think, it's too monstrous element to use it in markdown.Other markdown elements are not so needed imho. What do you think? Is that content useful?
P.S.
You can check out my repo https://github.com/dudeonthehorse/normalize.email.css
I tried to normalize default html elements for best email compatibility. Yes, I know — need to improve my library. I'll do my best. Hope, you'll be interest.
When Office 365 and the new Outlook.com encounter an empty href, it will remove the <a> tag but leave its content. For example…
<a href="">Hello world</a>… would become :
Hello worldWhen you have any content other than a URL inside a href, Office 365 and the new Outlook.com will show this content inside the email between brackets. So the following example…
<a href="Hello">world</a>… would become :
[Hello]worldThis bug was discussed on Litmus Forums here.
The french webmail of Orange replaces every occurrences of certain words by java-script(even when they're used in a sentence, or are part of a URL). I reported this on my blog two weeks ago after seeing it affected the word overflow (causing a potential security issue for Stack Overflow emails for example). I've since tested the keywords from this Event reference in JavaScript. Here are the words affected :
AOL incorrectly replaces the path of a background-image when used in a <style> tag. It wraps the URL of the image with an <a> tag linking to the image itself. The following example…
<style type="text/css">
.test {
background-image:url("http://i.imgur.com/A4kblQ3.jpg");
}
</style>… becomes :
<style type="text/css">
.test {
background-image:url("<a href="http://i.imgur.com/A4kblQ3.jpg"" target=_blank>http://i.imgur.com/A4kblQ3.jpg"</a>;);
}
</style>The same thing happens if you use single quotes or no quotes at all. It happens with the background-image property and the background shorthand. It happens no matter if the <style> tag is in the <body> or the <head>.
It doesn't happen when using background or background-image inline in a style attribute.
When opening an email in the french webmail of SFR (http://webmail.sfr.fr) in Internet Explorer, it looks like all media queries behave unexpectedly. But if we resize the window, even by just one pixel, everything goes back to normal. I reproduced this bug in Internet Explorer 10 and 11 on Windows 8.1.
Here's a test example :
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<title>SFR Media Query Bug</title>
<style type="text/css">
body { font:1em/1.5 sans-serif; margin:1.5em; background:#fff; }
div { padding:1em 1.5em; margin-bottom:1.5em; background:#FF4136; }
@media (max-width:320px) {
body { padding:0; }
.mq-maxwidth320 { color:#fff; background:#2ecc40; }
}
@media only screen and (max-width:320px) {
body { padding:0; }
.mq-onlyscreen-maxwidth320 { color:#fff; background:#2ecc40; }
}
@media (min-width:0) and (max-width:320px) {
body { padding:0; }
.mq-minwidth0-maxwidth320 { color:#fff; background:#2ecc40; }
}
@media only screen and (min-width:0) and (max-width:320px) {
body { padding:0; }
.mq-onlyscreen-minwidth0-maxwidth320 { color:#fff; background:#2ecc40; }
}
@media (min-width:1024px) {
body { padding:0; }
.mq-minwidth1024 { color:#fff; background:#2ecc40; }
}
@media only screen and (min-width:1024px) {
body { padding:0; }
.mq-onlyscreen-minwidth1024 { color:#fff; background:#2ecc40; }
}
</style>
</head>
<body>
<div class="mq-minwidth0-maxwidth320">
@media (min-width:0px) and (max-width:320px)
</div>
<div class="mq-onlyscreen-minwidth0-maxwidth320">
@media only screen and (min-width:0px) and (max-width:320px)
</div>
<div class="mq-maxwidth320">
@media (max-width:320px)
</div>
<div class="mq-onlyscreen-maxwidth320">
@media only screen and (max-width:320px)
</div>
<div class="mq-minwidth1024">
@media (min-width:1024px)
</div>
<div class="mq-onlyscreen-minwidth1024">
@media only screen and (min-width:1024px)
</div>
</body>
</html>Here's the render on load :
And here's the render after resizing the window :
The desktop and mobile webmails of Onet.pl remove any HTML comments.
The following example:
<p>This is a p element.</p>
<!-- <p>This is an HTML comment.</p> -->
<!--[if mso]>
<p>This is a mso conditional comment.</p>
<![endif]-->
<!--[if !mso]><!-->
<p>This is a !mso conditional comment.</p>
<!--<![endif]-->
<!--[if foobar]>
<p>This is a foobar conditional comment.</p>
<![endif]-->
…is transformed by Onet.pl into the following:
<p>This is a p element.</p>
Thanks to Thea Cruz for making me discover this email client and bug on the #emailgeeks Slack.
Background-images aren't loaded in Office365 in Litmus and in my office365 as well. They only show when you click on “To always show content from this sender, click here”.
Because outlook.com using the same rendering engine I imagine that this could be the case for outlook.com as well, but I wasn't able to reproduce the same situation in outlook.com. Does anyone know how to change the preferences for downloading images in outlook.com/office365?
I tried background attribute, shorthand and longhand(?) css and it seems that these all get stripped.
The new Gmail still replaces any doctype in an HTML email by a <u></u> tag, just like the old Gmail. But on Internet Explorer 11, when images are not displayed by the new Gmail, the <u> tag wraps the entire email. Thus, every text appears underlined.
Here's an example in the new Gmail:
Here's the same example in the old Gmail:
Turning the images on solves the problem.
In iOS 10 (and the first beta of iOS 11 as well), Apple Mail incorrectly scales email that contains a fixed width larger than the device viewport and a max-width of 100% (like width:800px; max-width:100%;).
Here's an example (and here's the code).
Having the <meta name="x-apple-disable-message-reformatting" /> tag doesn't make any difference. Inverting the width and max-width values to avoid the definition of a fixed width solves the problem (like width:100%; max-width:800px;).
If you include an emoji anywhere in a <style> tag, Outlook.com won't display anything and show a blank email instead. The following example…
<!doctype html>
<html>
<head>
<style type="text/css">
.🍌 {
background:#f5bb47;
color:#fff;
}
</style>
</head>
<body>
<h1 class="🍌" style="font-size:2em; font-family:sans-serif; padding:1em; Margin:0;">Banana.</h1>
<p>
Lorem ipsum dolor sit amet, consectetur adipisicing elit. Culpa maiores amet, praesentium eius. Recusandae sint laudantium amet molestias, illo, eum ratione in iusto, at necessitatibus omnis. Illum, corrupti rerum nobis?
</p>
</body>
</html>…will be displayed like this :
The mobile webmail of french provider La Poste has a generic style rule that resets width on all elements.
.email__body-content * {
width: auto !important;
}One possible solution to override this is to add an !important on inline declarations as well. But because this would not work in Outlook 2007-2019, you'd need to add the width property twice, as such:
<div style="width:50%; width:50% !important;"></div>Yahoo removes rgba color declarations for certain CSS properties, like border, text-shadow or outline. The following code:
<style>
div {
text-shadow:.1em .1em rgba(0,0,0,0.5);
border:1px solid rgba(0,0,0,0.5);
outline:1px solid rgba(0,0,0,0.5);
}
</style>…is transformed by Yahoo into:
<style>
div {
text-shadow:.1em .1em;
border:1px solid;
outline:1px solid;
}
</style>This might be problematic because in CSS, if a text-shadow declaration doesn't have a color specified, it defaults to the currentColor CSS variable which matches the font color. This makes text-shadow unreliable in Yahoo with rgba colors.
For other properties (like background-color or color), Yahoo doesn't support rgba colors either, but it will strip the entire property.
Gmail and Yahoo convert the CSS height property to min-height. The following code :
<img src="http://i.imgur.com/0HuZSwt.jpg" alt="" width="636" height="347" style="width:100%; max-width:636px; height:auto;" />…is turned into :
<img src="http://i.imgur.com/0HuZSwt.jpg" alt="" width="636" height="347" style="width:100%; max-width:636px; min-height:auto;" />This is problematic because the image might now appear squashed if it's displayed below it's maximum width. In order to prevent this, it's best advised to avoid using the height attribute in HTML and be cautious when using height in CSS.
This happens across all Gmail clients (desktop webmail, mobile webmail, iOS app, Android app, and Inbox clients as well) and Yahoo clients (desktop webmail, iOS app).
This was also discussed here :
Outlook.com filters some properties depending on their case. For example, Outlook.com supports Margin:0; but not margin:0;. I tested every properties based on this list, and 19 properties affected by this behavior. Some will only work when written in lowercase. And others will only work when written in anything but lowercase.
Properties only supported in lowercase :
Properties only supported in anything but lowercase :
In previous versions of Apple Mail, sending the example markup, an email recipient had the ability to scroll through the content using a trackpad, or mouse scroll wheel. This is no longer working as expected, and can be considered a bug.
I have tested and confirmed this is the case in:
All versions iOS appears unaffected, at the moment :)
<!DOCTYPE html>
<html lang="en">
<head>
<title>Apple Mail || CSS overflow test</title>
<style>
body { font:30px sans-serif; color: #fff; }
</style>
</head>
<body class="body">
<div style="height:200px; border:11px solid orange; overflow:scroll;">
<div style="margin:11px; border:11px dashed purple; background:teal;">
<h2>Lorem ipsum</h2>
<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>
<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>
<h2>Lorem ipsum</h2>
<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>
<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>
</div>
</div>
</body>
</html>
Yahoo (the desktop webmail or the iOS Android apps) don't support certain class names in a <style> declaration containing underscores or dashes at the start or end of the class name. The styles are incorrectly prefixed. I've listed these cases:
._foo, .__bar). In these cases, the dot and underscores at the start of the style rule are removed. So .__foo { } becomes foo { }..foo__). In this case, the last underscore is removed in the style rule. So .foo__ { } becomes .foo_ { }..-foo). In this case, the dot and dash are removed at the start of the style rule. And the class is completely removed from the HTML. So .-foo { } becomes .-foo { } and <div class="-foo"> becomes <div> .Here's a code example:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Yahoo</title>
<style>
div { padding:0.5em; color:#fff; font:1em sans-serif; margin-bottom:0.25em; background: #c44230; }
._foo { background: #39b54a !important; }
.__foo { background: #39b54a !important; }
.foo__ { background: #39b54a !important; }
.-foo { background: #39b54a !important; }
.--foo { background: #39b54a !important; }
</style>
</head>
<body>
<div class="_foo">._foo</div>
<div class="__foo">.__foo</div>
<div class="foo__">.foo__</div>
<div class="-foo">.-foo</div>
<div class="--foo">.--foo</div>
</body>
</html>This will be transformed by Yahoo into the following:
<div id="yiv6762051608">
<title>Yahoo</title>
<style>
#yiv6762051608 div
{
padding:0.5em;
color:#fff;
font:1em sans-serif;
margin-bottom:0.25em;
background:#c44230;
}
#yiv6762051608 foo
{
background:#39b54a !important;
}
#yiv6762051608 foo
{
background:#39b54a !important;
}
#yiv6762051608 .yiv6762051608foo_
{
background:#39b54a !important;
}
#yiv6762051608 -foo
{
background:#39b54a !important;
}
#yiv6762051608 --foo
{
background:#39b54a !important;
}
</style>
<div id="yui_3_16_0_ym19_1_1477054134840_4745">
<div class="yiv6762051608_foo" id="yui_3_16_0_ym19_1_1477054134840_4748">._foo</div>
<div class="yiv6762051608__foo" id="yui_3_16_0_ym19_1_1477054134840_4747">.__foo</div>
<div class="yiv6762051608foo__" id="yui_3_16_0_ym19_1_1477054134840_4744">.foo__</div>
<div id="yui_3_16_0_ym19_1_1477054134840_4767">.-foo</div>
<div id="yui_3_16_0_ym19_1_1477054134840_4768">.--foo</div>
</div>
</div>Hat tip to Mark Robbins and Wilbert Heinen for mentioning this bug on the #emailgeeks slack yesterday.
Example:
ul { padding: 0; } was ignored. Yahoo added its .undoreset ul { padding-left: 40px; }
body {
font-family: Helvetica, Arial, sans-serif;
font-size: 12px;
color: #333333;
line-height: 16px;
}
/*comment in code*/
ul {
padding: 0;
margin: 0 0 0 15px;
}
ul ul { margin: 0 0 5px 15px; }
li { margin: 0 0 5px 0; }`Corrected example:
Once the comment has been removed, the ul { padding: 0; } will be respected.
body {
font-family: Helvetica, Arial, sans-serif;
font-size: 12px;
color: #333333;
line-height: 16px;
}
ul {
padding: 0;
margin: 0 0 0 15px;
}
ul ul { margin: 0 0 5px 15px; }
li { margin: 0 0 5px 0; }`Couple of times I ran into issues with dashed borders on Outlook 2007 & 10. Between dashes the color assigned for body shows up.
What happens on the example below is instead of creating dashed border with #ffffff & #92CECD colors, it gets the second color from body. So #92CECD changes to #58595B.
EXAMPLE:
<body style="margin:0px; padding:0px; background-color:#58595B;">
<table width="100%" border="0" cellspacing="0" cellpadding="0" align="center">
<tr>
<td align="center" valign="top"><table align="center" class="main_table" width="650" border="0" cellspacing="0" cellpadding="0" style="table-layout:fixed;" bgcolor="#ffffff">
<tr>
<td><table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td height="20" bgcolor="#92CECD" style="font-size: 3px; line-height:3px; border-top: 2px dashed #ffffff; "> </td>
</tr>
</table></td>
</tr>
</table></td>
</tr>
</table>
</body>
First Example
<table>
<tr>
<th> </th>
<th>text</th>
<th> </th> <!-- this will be eaten -->
</tr>
</table>Second Example
<table>
<tr>
<th> </th>
<th>text</th>
<th> </th> <!-- this will be ok -->
</tr>
</table>
<table>
<tr>
<th> </th> <!-- this will be eaten -->
</tr>
</table>If we change to • or another special char, it's will works fine.
Yesterday, an interesting conversation was started on the #emailgeeks Slack by @cossssmin regarding Gmail clipping limit.
Do we have a source for the magic 102KB message size Gmail clipping limit? I'm curious if someone actually tested this or if it was communicated from an official source, as I've been blindly following it (like most of us probably have), and I've recently seen emails that were 99.something KB getting clipped (before you ask, it was after ESP added stuff to it).
A few people, including myself, weighed in to share their experience and a few test results, but without a definitive answer yet. I loved the little collaborative investigation that went on for a few hours, but it seems Slack is not really appropriate for this (given the temporary nature of conversations there). So I thought here would be a good place to continue this together.
When HTML emails are too large, Gmail clips them with a [Message clipped] notice and a View entire message link. It's been widely shared that this clipping occurs after 102Kb (example: Gmail is clippin my email on Mailchimp). But no one seems to know where this number comes from. And different people have experience different results around the 100Kb mark.
So what is going on exactly? Can we figure out Gmail's clipping algorithm?
On the desktop webmail of Gmail, when Gmail is set up to "Ask before displaying external images", a banner with "Images are not displayed" appears on top of an email with a link "Display images below".
If you click on the "Display images below" link, the HTML of your email will be reparsed but with a different prefix than the one used in the CSS. Thus, CSS rules no longer match the HTML, and emails might appear broken.
Here's an example.
<!DOCTYPE html>
<html>
<head>
<title>Gmail "Display Images Below" Bug</title>
<style>
p { background:#c44230; display:block; padding:1em; font: 1em/1.5 Open sans, sans-serif; color:#fff; }
.foo { background:#39b54a; }
</style>
</head>
<div>
<p class="foo">
Lorem ipsum dolor sit amet, consectetur adipisicing elit. Possimus atque nisi iure, iusto fugit cumque odio eos ipsa, recusandae molestiae hic magnam vero suscipit velit unde voluptates eaque non qui.
</p>
<img src="http://i.imgur.com/HhAfOct.gif" alt="This image is blocked." style="display:block; width:200px; height:100px;" />
</div>
</html>On display, images are blocked. The HTML is turned into the following:
<div id=":3a" class="a3s aXjCH m159215f7d36ee7fd">
<u></u>
<div>
<p class="m_3567455155959655244foo">
Lorem ipsum dolor sit amet, consectetur adipisicing elit. Possimus atque nisi iure, iusto fugit cumque odio eos ipsa, recusandae molestiae hic magnam vero suscipit velit unde voluptates eaque non qui.
</p>
<img alt="This image is blocked." style="display:block;width:200px;height:100px">
</div>
</div>And the styles are prefixed like this:
div.m159215f7d36ee7fd p {
background:#c44230;
display:block;
padding:1em;
font:1em/1.5 Open sans,sans-serif;
color:#fff
}
div.m159215f7d36ee7fd .m_3567455155959655244foo {
background:#39b54a
}If you click on the "Display images below" link, the HTML code is turned into the following:
<div id=":3a" class="a3s aXjCH m159215f7d36ee7fd">
<u></u>
<div>
<p class="m_-8249599400804587256foo">
Lorem ipsum dolor sit amet, consectetur adipisicing elit. Possimus atque nisi iure, iusto fugit cumque odio eos ipsa, recusandae molestiae hic magnam vero suscipit velit unde voluptates eaque non qui.
</p>
<img src="http://i.imgur.com/HhAfOct.gif" alt="This image is blocked." style="display:block;width:200px;height:100px" class="CToWUd">
</div>
</div>While the main m159215f7d36ee7fd prefix is kept the same, prefixes inside the email have changed. The class foo, first prefixed into m_3567455155959655244foo now becomes m_-8249599400804587256foo. The styles in the <head> haven't changed accordingly, so styles don't apply anymore.
Hat tip to Mark Robbins and Stig Morten Myre for sharing this bug on the Email Geeks Slack and on this Campaign Monitor post.
As reported here, Office 365 trims values of the inline CSS property font-family whenever there's a \ inside an @ declaration in a <style> tag.
The following example…
<style type="text/css">
@ { "\" }
</style>
<p style="font-family: 'Indie Flower', 'Arial', 'Helvetica', 'Lucida Grande', 'sans-serif';">
Lorem ipsum dolor sit amet.
</p>…will be transformed by Office 365 into the following :
<style type="text/css"><!-- --></style>
<div>
<div>
<p style="font-family:'ni ">Lorem ipsum dolor sit amet. </p>
</div>
</div>This doesn't happen if we remove the @ { "\" } part in the <style> tag. Now the truncating is different if every font in the font-family stack is declared between quotes (or double quotes), and if there is no quote.
If every font is declared between quotes (or double quotes), the trimming algorithm Office 365 employs looks like something like this. Count the number of fonts declared in the font stack, and substract two (and let's call this n). Then start after the first opening quote (or double quote) in the font stack and only keep the first n odd characters. This is why in the previous example, the following font stack :
'Indie Flower', 'Arial', 'Helvetica', 'Lucida Grande', 'sans-serif'…is transformed into :
'ni This behavior is completely different if any of the font in the font stack is between quotes (or double quotes). The following code :
<style type="text/css">
@ { "\" }
</style>
<p style="font-family: 'Indie Flower', 'Arial', 'Helvetica', 'Lucida Grande', 'sans-serif';">Test 1</p>
<p style="font-family: 'Indie Flower', 'Arial', 'Helvetica', 'Lucida Grande', sans-serif;">Test 2</p>
<p style="font-family: 'Indie Flower', 'Arial', 'Helvetica', Lucida Grande, sans-serif;">Test 3</p>
<p style="font-family: 'Indie Flower', 'Arial', Helvetica, Lucida Grande, sans-serif;">Test 4</p>
<p style="font-family: 'Indie Flower', Arial, Helvetica, Lucida Grande, sans-serif;">Test 5</p>
<p style="font-family: Indie Flower, Arial, Helvetica, Lucida Grande, sans-serif;">Test 6</p>…is transformed into :
<style type="text/css"><!-- --></style>
<div>
<div>
<p style="font-family:'ni ">Test 1</p>
<p style="font-family:'ni lower', 'A">Test 2</p>
<p style="font-family:'ni Flower', 'Aril', 'Helve">Test 3</p>
<p style="font-family:'nie Flower' 'Arial', Helvtica, Luci">Test 4</p>
<p style="font-family:'ndie Fower', Aril, Helvetica, ucida Gran">Test 5</p>
<p style="font-family:Indie Flower,Arial,Helvetica,Lucida Grande,sans-serif">Test 6</p>
</div>
</div>Outlook 2007, 2010, 2013, and 2019 do not respect the !important declaration when used with inline styles.
<style>
span { font-family: 'Times New Roman'; }
</style>
<span style="font-family: Arial !important;">
Will display in Times New Roman
</span>
<span style="font-family: Arial, sans-serif !important;">
Will display in Times New Roman.
</span>
<span style="font-family: Arial, sans-serif!important;">
In this special case it will display in Arial. Here only 'sans-serif' is
invalidated because it's connected to the `!important` declaration. Instead
of the whole property being invalidated, only the last font is invalidated.
</span>
This bug is not exclusive to font-family, all inline styles are subject to this bug.
However, with font-family it will treat fonts that are directly touching !important (meaning no space separating them) as invalid. This essentially cancels out the font AND the !important declaration. As a result it won't invalidate your whole font stack.
Note that the !important declaration works as intended within <style> tags.
###Other !important Issues
You can use !important in <style> tags, but in at least Outlook 2019 a space between your property and !important is required for it to work.
The desktop webmail of Yahoo removes any !important declaration when used on a display property with a space separating the value and the important declaration. Thus the following example…
display:inline-block !important;… will be transformed by Yahoo into :
display:inline-block;However, the following will be kept intact :
display:inline-block!important;This was discussed on Litmus forums a month ago.
The desktop webmail of french provider Orange has several default styles that can be quite annoying to tackle the first time. The styles can be found at:
The CSS filename presumably changes at every update from their part.
Among the most notoriously annoying rules is the following:
table {
margin:0;
}This overrides any align attribute on a <table>. So if you want to center a <table> in Orange's webmail, you must use <table align="center" style="margin:0 auto;">.
Another seemingly annoying rule is the following:
td {
vertical-align:top;
}This will override any valign attribute on a <td>. So if you want to vertically align something at anything else than top, you must use <td style="vertical-align:bottom;">.
I'm writing about this bug for archives and historical purposes. On November, 22nd 2017, Google deployed a server side update affecting its Inbox clients (desktop webmail, and both iOS and Android apps). The Gmail iOS app was also impacted. This update had for effect to replace some special characters by an equivalent image from Google's own emoji assets. The most notable characters affected were ©, ® and ™.
| Character | Image replacement |
|---|---|
| © | |
| ® | |
| ™ |
Here are a few examples of how this impacted emails.
A fix suggested by Mark Robbins consisted in using similar looking symbols, like ⓒ, Ⓒ, ⓡ, Ⓡ or <sup>TM</sup>. This was heavily discussed by the community here.
This bug was later fixed by Google during the month of December.
Yahoo's desktop webmail seems to add the CSS property overflow-x:auto; when it sees the property max-width inline, and overflow-y:auto; when it sees the property max-height.
For example, the following code…
<div style="max-width:50px; max-height:50px;>Lorem ipsum</div>
… will be transformed by Yahoo into :
<div style="overflow-x:auto;max-width:50px;overflow-y:auto;max-height:50px;">Lorem ipsum</div>A fix consists of adding an overflow:visible property. So the following code…
<div style="max-width:50px; max-height:50px; overflow:visible;>Lorem ipsum</div>
… will be transformed by Yahoo into :
<div style="overflow-x:auto;max-width:50px;overflow-y:auto;max-height:50px;overflow:visible;">Lorem ipsum</div>However, this won't work on Internet Explorer because Yahoo also adds -ms- prefixed versions of the overflow- properties. So the latest example becomes on Internet Explorer :
<div style="overflow:visible; -ms-overflow-x:auto; -ms-overflow-y:auto; max-height:50px; max-width:50px;">Lorem ipsum</div>A known hack in Outlook.com (both in the actual version, the current beta and Office 365) is that the webmail filters attribute selectors. So the following code:
[owa] .foo { }
…becomes:
.foo { }
I've shared this on Twitter in january 2016, and it became a famous hack to target Outlook.com. But this is also a very practice because it completely changes the intent of the original selector.
Just this morning, I realized that Outlook.com does something different when using attribute selectors on an HTML element. Thus the following code:
a[x-apple-data-detectors] { }
…becomes:
ax_[x-apple-data-detectors] { }
The uses of a x_ prefix is common throughout Outlook.com as class and id attributes values are also prefixed the same way. But it makes an interesting difference for attributes as the selector is now more "safely" filtered. The original intent of the selector is made invalid, and not changed to another meaning.
The desktop webmail of Yahoo has a default style rule targeting any element with a dir attribute.
[dir] {
text-align:start;
}Thus it breaks the cascade if you wanted to inherit text-align from a parent element. Any element with a dir attribute should also include a text-align style inline.
<html>
<head><!-- Yahoo App Android will strip this --></head>
<head>
<meta ... >
<style>
your styles
</style>
</head>
<body>
your content
</body>
</html>
Using an empty <head> tag first will prevent Yahoo! Mail app for Android from stripping out your styles.
Use this with caution. Some ESPs will process your code before sending it. In many cases this involves accepting the first <head> tag and deleting the rest. MailChimp for example will do exactly this, leaving you with no <style> tag.
Outlook '13 and '16 have a bug where if more than one table is nested inside of a VML object (specifically for the purpose of a background-image), left padding will fail for the first, second and all remaining nested tables.
Case 1
<vml>
<table><tr><td style="padding: 40px;">
Padding works as intended with 40px on all 4 sides. For most cases, additional nesting is not necessary for layout.
</td></tr></table>
</vml>
Case 2
<vml>
<table><tr><td style="padding: 40px;">
<table><tr><td>
Initial td is used as a container, and a second nested table will be used for content. In this case, Outlook '13 and '16 fail to render the left padding on the containing td. The remaining 3 padding properties work as intended.
</td></tr></table>
</td></tr></table>
</vml>
Case 3
<vml>
<table><tr><td style="padding: 40px;">
<table><tr><td style="padding: 40px;">
To see how far the rabbit hole went, I decided to keep nesting tables and adding padding to all, or only the next closest table to the content. In the end, it seems that any additional table nested after the first will render any and all left-padding irrelevant.
</td></tr></table>
</td></tr></table>
</vml>
Inversely, both clients render margin-left as intended, without supporting the other 3 margin attributes under these circumstances.
Therefore, we can add a class/id and padding to a td (this would be a Case 2 scenario, acting as a container fix) <td class="padding" style="padding: 40px;"> and use conditional css to add a left margin for Outlook clients greater than or equal to 13.
<!doctype html>
<html>
<head>
<!--[if gte mso 13]>
<style type="text/css">
.padding { margin-left: 40px !important; padding-left: 0 !important; }
</style>
<![endif]-->
</head>
<body>
<vml>
<table><tr><td class="padding" style="padding: 40px;">
<table><tr><td>
Hello world! I'm nested and padded!
</td></tr></table>
</td></tr></table>
</vml>
</body>
</html>
Setting the padding-left attribue to 0 doesn't seem to have any effect in the conditional css.
A point was brought up to use the inset value on the <v:textbox> element, but that would have adverse affects in conjunction with the padding for all remaining MSO clients that do render it properly. This approach tries to tackle the problem directly, by fixing the CSS that should be valid in the first place.
EoA test for reference.
https://www.emailonacid.com/app/acidtest/tM4rWkVK9Ptna79iMhKldDRiymezJ7L7Al2vKJ9KH9Vug/list
Test File -
mso_13+16_pad_fix.zip
UPDATE
Second alternative option without declaring classes or css styles is to override the padding directly inline with
<!doctype html>
<html>
<body>
<vml>
<table><tr><td class="padding" style="padding-top: 40px; padding-right: 40px padding-bottom: 40px; padding-left: 40px; mso-padding-right-alt: 0; mso-padding-left-alt: 0;">
<table><tr><td>
Hello world! I'm nested and padded!
</td></tr></table>
</td></tr></table>
</vml>
</body>
</html>
This approach can't mix short/long format, so all padding properties must be explicitly expressed for this version to work correctly.
Testing device: iphone 6s with Ios version: 10.2.1 and native mail app.
How letter looks on PC:
How it looks on mobile:
How it looks on IOS 10 and apple mail app:
It is pretty large (~50kb) and long mail, but it works well with all clients and devices except apple mail. Maybe someone met this problem and know any workaround?
Outlook.com, on both mobile and desktop, prefixes every CSS rules by .ExternalClass. This works great on desktop. However, on mobile, the ExternalClass is nowhere to be found anywhere in the HTML. This makes every CSS rule inoperative on mobile.
So for example, the following rule :
<style type="text/css">
.test {
padding:1em 1.5em;
color:#fff;
background:#2ecc40;
}
</style>
<div class="test">Test</div>… becomes :
<style type="text/css">
.ExternalClass .ecxtest {
padding:1em 1.5em;
color:#fff;
background:#2ecc40;
}
</style>
<div class="ecxtest">Test</div>This works great on desktop because the email is wrapped by a <div class="ExternalClass MsgBodyContainer">. On mobile, the email is wrapped by a <div class="mv_body" id="mv_body0">. This wrapper (or any of its parent element) should also have the ExternalClass class.
Gmail removes any <style> tags or inline style attribute that contains an uppercase !IMPORTANTdeclaration.
The following code…
<html>
<head>
<style>
div { background:#2ECC40; }
p { color:#fff !important; }
</style>
<style>
div { background:#FF4136; }
p { color:#fff !IMPORTANT; }
</style>
</head>
<body>
<p style="color:#fff !important; background:#2ECC40;">
Lorem ipsum dolor sit amet, consectetur adipisicing elit.
</p>
<p style="color:#fff !IMPORTANT; background:#FF4136;">
Lorem ipsum dolor sit amet, consectetur adipisicing elit.
</p>
</body>
</html>…is transformed by Gmail into the following :
<html>
<head>
<style>
div { background:#2ECC40; }
p { color:#fff !important; }
</style>
</head>
<body>
<p style="color:#fff !important; background:#2ECC40;">
Lorem ipsum dolor sit amet, consectetur adipisicing elit.
</p>
<p>
Lorem ipsum dolor sit amet, consectetur adipisicing elit.
</p>
</body>
</html>As per CSS 2 specification, "all CSS syntax is case-insensitive".
This was discovered and reported by Sam Lewis on the Litmus forums.
The desktop webmail of T-online.de content within HTML conditional comments. So the following example:
<!-- <p>This is an HTML comment.</p> -->
<!--[if mso]>
<p>This is a mso conditional comment.</p>
<![endif]-->
<!--[if foobar]>
<p>This is a foobar conditional comment.</p>
<![endif]-->…is transformed by T-online.de into the following:
<p>This is a mso conditional comment.</p>
<p>This is a foobar conditional comment.</p>
This only affects conditional comments (not regular HTML comments). And this works with any conditional keyword (like foobar in the previous example).
Thanks to @M-J-Robbins for spotting this one yesterday on the #emailgeeks Slack.
On IE9 (or using a Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0) user agent), Microsoft serves a different version of Outlook.com.
The CSS parser is pretty similar to the one on the regular Outlook.com (prefixing class and id attributes with x_ for example). Except it doesn't prefix CSS rules targeting tag names. At all. So it's possible to target elements from the webmail UI.
The following email hides all table elements and sets the body background in red.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Outlook.com Email bug</title>
<style>
body { background:red; }
table { display: none; }
</style>
</head>
<body>
<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit. Ad, in, accusamus! Qui dolores at magni maiores sunt, laudantium, optio libero ducimus unde reiciendis vero quas deleniti recusandae voluptatibus. Provident, accusantium.</p>
</body>
</html>As reported by Wassif A. on the #emailgeeks slack, Outlook.com has a new default style that resets the max-width property for images inside tables. Here's the incriminated rule :
._3z9ix0Ue99trWXkNz-xubm table img {
max-width: none!important;
}
Here's a test email :
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Outlook.com max-width reset</title>
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0" role="presentation" style="width:100%;">
<tr>
<td>
<div style="max-width:200px; width:100%;">
<p style="margin:0; padding:1em; color:#fff; background:#ff4136;">The image below shouldn't exceed 200px wide.</p>
</div>
<img src="https://i.imgur.com/l530ez3l.jpg" alt="" style="display:block; width:100%; max-width:200px;" width="2294" />
</td>
</tr>
</table>
</body>
</html>
A solution could be to add an !important inline on each image. Like this :
<img src="https://i.imgur.com/l530ez3l.jpg" alt="" style="display:block; width:100%; max-width:200px!important;" width="2294" />
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.