I've seen here and elsewhere that a recommended way to set up conditional comments to work with Outlook.com, but because of another known issue detailed below I'm getting blank emails. Referencing the two code examples below I wanted to see if anyone had a reliable way around this issue.
First example:
<!--[if mso]><!-- -->
<style type="text/css">
#learn-left { width: 350px; max-width: 350px; }
#learn-right { width: 165px; max-width: 165px; }
</style>
<!--<![endif]-->
The above code causes a blank screen in Outlook.com even though other posts here have cited that <!--[if mso]><!-- --> works with Outlook.com. I know there is any issue with having any HTML tags inside comments, but if the conditional is placed with the style tag it doesn't work either. Strangely the code below seems to work to a degree.
<!--[if mso]><!-- -->
<style type="text/css">
#learn-left { width: 350px; max-width: 350px; }
#learn-right { width: 165px; max-width: 165px; }
</style>
<![endif]-->
I should also note the reason I have this code is for Outlook 2000 and 2003 compatibility so I can't use media queries as an alternative solution.
Those sites that say you can do that are wrong. Outlook.com eats your conditional comments, and anything inside of them. Gave me quite a headache for a while.
For things where you need to use conditional comments, I found the best thing to do was to have the regular conditional comment section, but also include another table row / column or what have you with a class like class="outlookcom" (on the td) and hide it with display:none. Then, in your <style> tag you can target that hidden row with ecxoutlookcom (outlook prepends 'ecx' to all of your classed tags) and use display:block !important to show itfor outlook.com
I tried this, but it didn't work for me. It was showing stray comment tags onscreen.
<!--[if !gt mso 9]><!-- -->
/* css here */
<!--<![endif]-->
<!--[endif]-->
This is what worked for me. I tested it on email on acid. Seems to work perfectly.
<![if !mso]>
<div>
This shows on all clients but not outlook 2007, 2010, 2013.
Works fine on outlook.com.
</div>
<![endif]>
<!--[if gte mso 9]>
<div>
This only shows on outlook 2007, 2010, 2013
</div>
<![endif]-->
I
for more info, try searching for "microsoft downlevel revealed conditional comments"
I don't know if using CSS to hide/show is the best route to go since not all email clients will process/honor that css (I tested a version in the Outlook windows client and it didn't work). I think the reason Outlook.com is consuming the conditional branching is because the syntax people are using is slightly off. When I corrected my syntax, the code rendered correctly in both Outlook.com and Outlook the windows client. I also tried the iphone Outlook app, the iphone built in email app, and icloud (web) and the code renders correctly.
One thing to note is that if you are using razor script on IIS, be sure to wrap the if !mso in elements so IIS knows not to process it as razor script. Here is my code snippet:
<!--[if mso]>code to render in the Outlook client<![endif]-->
<text><!if !mso]>code to render in Outlook.com<![endif]></text>
Thanks to the hint given in the OP I just discovered a potential fix to the "blank outlook.com" problem: double end comments.
Instead of this:
<!--[if !gt mso 9]><!-- -->
/* css here */
<!--<![endif]-->
try this
<!--[if !gt mso 9]><!-- -->
/* css here */
<!--<![endif]-->
<!--[endif]-->
It appears as though most web clients will ignore the last closing comment (it is still a valid comment block, after all), but outlook.com won't, thus you get all the email clients taking notice of the comment section and in the case of outlook.com this means no blank emails. Obviously use with caution but from my limited testing through Litmus it looks like it works just fine.
Related
CSS has features specifically to support printing, designed for user agents intended for printing, the best known of which is probably Prince. Alas, browsers aren't such user agents, and Prince is expensive ($500 for the desktop version).
So I started looking into a closely-related problem: Whether it would be possible to produce properly paginated and formatted output using the print feature of a browser (Chrome, in my case), where the user agent (the browser) outputs to the screen, not to a printer, although it is able to print the contents of the browser window. (That's not the same thing as being a user agent for printing.) As anyone who's tried it finds out, Chrome (and probably other browsers) doesn't support the CSS #page rule. That means there's no practical way to, for example, distinguish between left and right pages, but in my case that didn't matter.
All I needed was:
Paginated output, and
Precise control over placement on the printed page.
Normally, when you print a browser page exact formatting isn't important. Think of a shipping label, a boarding pass, or notes for a meeting. But, in my case, the printed page is the critical part, and the browser rendition is merely a preview. Specifically, I was trying to prepare a PDF for a photo book for uploading to MagCloud, an on-demand magazine printing service (owned by Blurb, the book-printing people).
(Many apps, like Lightroom, have book layout capabilities, but for reasons not germane to this post I couldn't use any of them.)
So my question, which I'm also going to answer is: What's a simple way to produce precise printed output from a browser?
I found that, while Chrome doesn't support #page, it does support the page-break-before style. So, to get paginated printed output, all you have to do is something like this:
<!doctype html>
<html lang=en>
<head>
<meta charset=utf-8>
<title></title>
<style>
* {
margin: 0;
padding: 0;
}
.page {
position: relative;
page-break-before: always;
width: 5.5in;
height: 8.5in;
}
.inner {
position: relative;
top: .25in;
left: .25in;
width: 5in;
height: 8in;
border: 1px solid blue;
}
</style>
</head>
<body>
<div class=page>
<div class=inner>
<p>This is page one.
</div>
</div>
<div class=page>
<div class=inner>
<p>This is page two.
</div>
</div>
</body>
</html>
Note that I'm using inches instead of pixels, thus neatly avoiding the issue of the resolution of the printed page in pixels. (It happens to be 96, but I'm not using that fact, and it might be different on different systems anyway.) Millimeters would work as well.
Here's how it looked in my browser:
I found that the built-in Windows 10 PDF print driver isn't accurate, producing pages that don't reflect the sizes I set in CSS. The free CutePDF Writer, however, is dead on, as is Mac OS X.
Here's the PDF in Acrobat Reader:
As you can see, it's perfect. All you have to do is lay out your content inside the <div class=inner> and you're set. If you want a full-page bleed, such as for a book-cover photo, put the content directly in the <div class=page>.
In my application I generated the actual HTML from a PHP program, but this static HTML illustrates the important concepts.
We developed a application with older Version of IE7.
And the code contains "CSS expression" but this not working in IE11.
Sample code :
div#GridViewContainer
{
position: relative !important;
width: 1000px !important;
overflow: auto !important;
}
_:-ms-fullscreen, :root .staticHeader
{
position: relative !important;
top: expression(this.offsetParent.scrollTop);
z-index: 99 !important;
}
_:-ms-fullscreen, :root .StaticColumn
{
z-index: 90 !important;
border: 1px solid gray !important;
position: relative !important;
left: expression(document.getElementById("GridViewContainer").scrollLeft);
}
How to make work in IE11 and alternative way to do this?
How alter my code?
You could do the same using pure JavaScript and get rid of CSS expressions all together.
OR
If you are feeling lazy or dont want to use JS, try setting the Document mode:
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
add it to the <head>...</head> section.
Note that this can possibly break the properties not supported by IE7 that you may have used.
Why you should avoide using CSS Expressions:
Starting with Internet Explorer 11, CSS expressions are no longer
enabled for webpages loaded in the Internet zone. CSS expressions are
supported for pages loaded in other zones (such as the intranet zone)
when pages are rendered in IE7 standards mode or IE5 quirks mode.
-CSS expressions no longer supported for the Internet zone
Also,
Unfortunately, the performance penalty imposed by CSS expressions is
considerable, as the browser reevaluates each expression whenever any
event is triggered, such as a window resize, a mouse movement and so
on. The poor performance of CSS expressions is one of the reasons they
are now deprecated in IE 8. If you have used CSS expressions in your
pages, you should make every effort to remove them and use other
methods to achieve the same functionality
-Page Speed: Avoid CSS expressions (deprecated)
Conditional Comments should somewhat work as suggested by Leo Caseiroin in his answer, it will actually save you some bandwidth on IE7+.
I suggest you split your file with your hacks and than, you can use Conditional comments for IE, like so:
<link href="css/ie11-without-hacks.css" rel="stylesheet">
<!--[if lt IE 7]>
<link href="css/ie7hacks.css" rel="stylesheet">
<![endif]-->
About conditional comments:
https://msdn.microsoft.com/en-us/library/ms537512(v=vs.85).aspx
I am designing an HTML email and I've made it look as good as I can in the email clients I have tested. I'm checking it now it Outlook.com and it has some issues (probably because they don't support margins) so I want to add some conditional styles for that client.
I know that Outlook.com wraps the email in a .ExternalClass class and prepends any custom classes with ecx so I tried something like
* {color:black;}
.ExternalClass * {color:red;}
.ExternalClass .ecxMyClass {color:blue;}
.ExternalClass .MyClass {color:green;}
just to see what selector would change the color of the text. I can't get any of them to work. Also I can't find where my styles are defined using an inspector like Firebug..
According to http://www.campaignmonitor.com/css/ Outlook.com should support style tags in the head or body and should be able to use classes as selectors.
Pretty much all of my styles are defined inline but I want to add padding to an element only in Outlook.com so I can't just add it inline. How do I target my custom class element in Outlook.com?
I'd strongly suggest you remove the margins from your email and use padding or empty (nbsp) table cells instead. Both are 100% supported, and as you're beginning to discover, jumping through hoops for certain clients can get really messy really quickly. Empty table cells with nbsp's in them are the best option as sometimes padding can get removed if your subscriber forwards the email to someone else.
That being said, if you want to target Outlook and not other clients, there are conditional mso tags that can be used.
Not sure if it works for Outlook.com, but give this a try:
<!--[if gte mso 15]><!-->
// This will only be seen by Outlook 2013
<![endif]-->
CSS is a different ball game for Outlook. As I'm sure you've come across in coding for email, there are severe limitations and it's often better to scale back your expectations than try and make something work.
Here is a link to what CSS styles will work for various email clients
http://www.campaignmonitor.com/css/
Outlook.com will eat conditional comments, so none of the above will work properly.
See this thread for details of an alternate approach.
The mso tags doesn't work anymore apparently, try this css hack instead
<!DOCTYPE html>
<html>
<head>
<style type="text/css">
/* This will be specific to outlook.com */
span[class~=x_outlook] {
color: #26d0ae;
}
/* This styling will work on the mobile apps of Microsoft Outlook (both ios and android) */
body[data-outlook-cycle] .outlook {
color: #26d0ae;
}
</style>
</head>
<body class="body">
Neutral
<span class="outlook">
This span is a chameleon
</span>
</body>
</html>
I've encountered something that bugged me while testing my email marketing campaigns.
So here goes:
I use the following code so that images and some other bits won't print when a user prints the e-mail (It is for a hotel group so emails are printed often, with booking numbers and all).
<style media="print">
body { background-color:#FFFFFF; }
.no-print { display:none; }
</style>
Now, outlook 2007/10/13, aol mail and some other clients seem to consider themselves as printed media and apply the display:none rule on every no-print element, leaving the email in a dire state of emptiness.
I could remove it all completely, but that wouldn't be good practices for ecology.
Do any of you guys know of a work around?
Like a way to force outlook to consider itself as a screen media?
Thanks a lot.
Now that I have a better understanding of the question I think I found the beginning of a possible solution for you. This should ensure the printer style sheets CSS still work, but aren't displayed by clients, like Outlook 2007, when they shouldn't be.
Ran test with email 'as is' and sure enough Outlook 2007 was blank because it applied the print style sheets
Then I added this media query in the code example below
Outlook 2007 shows up with the other clients so it's ignoring the print stylesheet
Now in Google Chrome's print preview the text with .no-print doesn't display
Code Excerpt:
<style media="print">
#media only print {
body { background-color:#FFFFFF; }
.no-print { display:none; }
}
</style>
</head>
<body >
<h1 class="no-print" style="font-size: 36px">LINE OF TEXT</h1>
Email Testing Link: https://litmus.com/pub/49bfd3b
I'm building a page which works fine in all browsers except IE6, where a small space appears below the cart. The background also has a gap in IE6, so I'm wondering what might be causing that, as it's probably related to the main issue.
If anyone could help I would really appreciate it! Many thanks.
Hi add this in your style file
#navigation {
width:736px;
height:auto;
background:url(../images/nav.gif) no-repeat;
float:left;
}
Have you tried adding a ie6 only stylesheet? Add this to the head tag and then add the appropriate styles to the css document and they should only apply to ie6.
<!--[if IE 6]><link rel="stylesheet" type="text/css" href="ie6_xxx.css"><![endif]-->