I used to use the code: [owa] .classname{css here};
If I filled the "css here" with for example display: none; the class would hide for outlook.com only.
But this code doesn't work for me anymore.
Because of this a great piece of my email doesn't show very well.
Does anyone know if there is a workaround for this?
Try this in your <style> tag:
[class="x_foo"] {
css here
}
Outlook.com prefixes class names with x_ but doesn't do it on attribute selectors. So <div class="foo"> can be targeted with [class="x_foo"] and it'll only apply to Outlook.com.
I don't believe the [owa] hack works anymore, so it can be safely removed.
I'm currently trying out Dygraphs (which seems really great btw!), but for some strange reason, the annotations feature won't work for me, AND it also fails in the exact same way on the jsFiddle version of Dygraphs' own gallery example of annotations, so this is most likely a bug/problem the devs really might want to take a look at(!).
To reproduce (same thing happens in both latest Firefox and latest Chrome):
1.
Look at the "annotations" example in the Dygraphs gallery, here:
http://dygraphs.com/gallery/#g/annotations
It works just fine and looks great, like this:
2.
Press the "Edit in jsFiddle" button, for that very example on that very page.
You are now sent to jsFiddle, and if you press the "Run" button there, the chart itself (colored curves etc) is shown just fine, but, only the "stems" of the annotation "signs" are shown, while the text contents of the annotations are all displayed as normal text to the left of the chart?! Like this:
Seems like some kind of CSS problem or similar to me, am I correct?
Since the example is Dygraphs' own example, which also works on their own site but not on jsFiddle, all suspicions of incorrectly formatted data or code can also be let go, I guess. It also happens to all my own Dygraphs charts on my own computer that I try to annotate, but this native Dygraphs gallery example is a much better example to investigate from I guess?
So, my question is of course, why does this happen, and how do I fix it to get the annotations working and displaying correctly?
ADDITION:
Let's make it even simpler, in order to isolate the problem without any hesitation.
Here is a very simple example for Dygraph annotations that I have put together on my own local disk (i.e. as a stand-alone HTML file):
<html>
<head>
<script type="text/javascript" src="dygraph.js"></script>
<link rel="stylesheet" src="dygraph.css" />
</head>
<body>
<div id="test_chart" style="width:750px; height:350px;"></div>
<script type="text/javascript">
var test_annotations = [
{
series: "TestCol1",
x: "2017-05-26",
shortText: "A",
text: "Test annotation",
cssClass: 'annotation'
}
];
testchart = new Dygraph(
document.getElementById('test_chart'),
"Date,TestCol1\n" +
"2017-05-25,110\n" +
"2017-05-26,80\n" +
"2017-05-27,75\n",
{}
);
testchart.setAnnotations(test_annotations);
</script>
</body>
</html>
When I open this file (locally with file:// in Chrome on my computer, having the latest dygraph.js and dygraph.css in the same directory), this is what I get:
As you can see, exactly the same problem as described above appears here, i.e. only the "stem" of the test annotation is visible in the graph itself, while the annotation text ("A") is displayed to the left of the graph.
The Firebug console is empty after having loaded this file, and no attempts (unsuccessful or otherwise) of loading any images are anywhere to be found in the Firebug network tab either.
Again, this very much feels like some kind of CSS positioning problem to me, but I may of course very well be wrong?
The answer to provide to this question would then be:
How, in as few and simple changes/steps as possible, would I get this local example PoC code for Dygraphs annotations to work as intended, i.e. showing the annotation text "A" inside a square at the correct position inside the graph (i.e. at the position where the "annotation stem" is currently just displayed, just as is done in the working example on the Dygraphs page, in my first screendump above in this question)?
Setting
position: absolute
solved the problem for me.
The gallery example loads images from dygraphs.com. When you load the demo on jsfiddle, it tries to load the images from jsfiddle, which doesn't work. dygraphs annotations are working fine, it's just that the image files are missing.
It seems that I was right about the CSS positioning problem after all.
The annotations are rendered by Dygraphs by adding the following HTML to the DOM of the page (this is the exact HTML for my test annotation in my local example code in the question test above, extracted live using Firebug):
<div style="font-size: 14px; left: 392.5px; top: 241.214px; width: 16px; height: 16px; color: rgb(0, 128, 128); border-color: rgb(0, 128, 128);" class="dygraph-annotation dygraphDefaultAnnotation dygraph-default-annotation annotation" title="Test annotation">A</div>
If I (as suggested by this SO question) add the CSS property position: relative to this div (manually, using Firebug), the graph suddenly looks like this:
See, the annotation text is now correctly positioned! It's still missing its opaque background and colored border though, but I guess this is just the result of even more CSS properties missing for some reason?
So, let's focus then on why there is missing CSS for the annotations I guess?
My best guess is that the dygraph.css file isn't properly loaded under certain conditions (apparently both on jsFiddle and locally on my computer, even though it is indeed there in the same directory as the HTML file and dygraph.js)? Or am I wrong?
A Firebug dump of the applied CSS for the annotation div seems to support this. Here is the CSS from Firebug for the annotation div of my local example (and also same in jsFiddle):
And here is the CSS for the same thing in the working instance in the gallery on the Dygraphs site:
See, the classes from dygraph.css is completely missing in my local example and in the jsFiddle example (even though indeed explicitly referenced in the class attribute of the annotation div's html code, as can be seen above), even though the CSS file is indeed there in the same directory as the dygraph.js file?!
#danvk, do you have any idea why this happens, and if Dygraphs could be patched somehow to avoid this from happening, and thus load all the CSS that it is supposed to for the annotations?
The only working hack-solution I can find for the moment is to dump the entire contents of dygraph.css inline in the <head> of the HTML file, as so:
<style>
/**
* Default styles for the dygraphs charting library.
*/
.dygraph-legend {
position: absolute;
font-size: 14px;
z-index: 10;
width: 250px; /* labelsDivWidth */
/*
dygraphs determines these based on the presence of chart labels.
It might make more sense to create a wrapper div around the chart proper.
top: 0px;
right: 2px;
*/
background: white;
line-height: normal;
text-align: left;
overflow: hidden;
}
...
/* For y2-axis label */
.dygraph-label-rotate-right {
text-align: center;
/* See http://caniuse.com/#feat=transforms2d */
transform: rotate(-90deg);
-webkit-transform: rotate(-90deg);
-moz-transform: rotate(-90deg);
-o-transform: rotate(-90deg);
-ms-transform: rotate(-90deg);
}
</style>
After that it's finally working fine:
Addition:
It seems like others too (1) (2) have this general problem regarding the loading of CSS files. No accepted answer to neither that SO question nor Mozilla support thread though, and indeed, none of the suggested answers work for me either. WTF, how can such a huge problem be generally unknown/unanswered? Please do also note that the same thing happens for me in both Chrome and Firefox, and also on multiple computers, out of which some have never opened the file before, so no strange cache-related effects should be involved either. Either way, it would seem like the bug is outside of Dygraphs' scope.
I'm afraid I'm late to the party, but it looks the problem is still valid (or workaround is not well documented). I was able to have better estimation of position by adding in index.html:
<style>
.dygraph-annotation {
position : relative;
display:inline-block;
}
</style>
However still annotations are not following the chart well:
The option attachAtBottom : true added to annotations might help here a bit, but still annotations are jumping on hovering graph (I guess this is because of legend taking some place)
All day trying to solve the same problem as the author at the beginning of this post. Yes, changing the CSN file allows you to somehow solve the problem, but everything worked by itself without dancing with a tambourine when I added this one line:
link rel = "stylesheet" href = "// cdnjs.cloudflare.com/ajax/libs/dygraph/2.1.0/dygraph.min.css" /
As always, you need to be more attentive to the little things)
how to crop image for email template? I have an image that is of particular width (example 520px). I want to ensure that the height is never more than 150px. This is for email only... If I use max-height or just height css, then it gets pixelated? What other better option do I have?
Ideally, you would crop the image (either manually or programmatically), and have it stored somewhere (on a CDN), where you can embed the image, and it will display as intended.
If this ^ isn't an option, your limitations are based on what email clients you need to support.
I am using Campaign Monitor CSS as a reference.
Option 1: If you aren't concerned with supporting Outlook.com and/or Outlook 2007/10/13, you could set the image as a background property on an element as such:
<div style="
width: 520px;
height: 150px;
background-image: url(http://placehold.it/520x520)">
</div>
Here we are using a 520x520 (square) image, and setting the parent element to the desired size (520x150 as per your example).
Now you are faced with the issue of positioning the image background. As per the guide, if you attempt positioning, you will lose Gmail, which is probably a deal breaker. However, as an exercise, you could do this:
<div style="
width: 520px;
height: 150px;
background-image: url(http://placehold.it/520x520);
background-position: 50%;>
</div>
Now you've got an image positioned (centered), at your desired size. on an element.
Option 2: Is also limited to a specific set of clients. You could feasibly use position: relative, on the wrapper, and position: absolute, on the tag. Then use top, left properties to position.
Of course, you lose Yahoo, in addition to Outlook and Gmail.
HTML emails are tricky. I'm sure there are several other options out there. I hope this response gets you pointed in the right direction.
With various mail clients having limited support for html and CSS attributes you're going to have to have trouble achieving a cropped image affect using vanilla CSS and HTML techniques.
The following is supported by most mail clients other than Outlook and Outlook.com
<div style="
width: 520px;
height: 150px;
background-image: url(http://placehold.it/520x200.jpg)
"></div>
Unfortunately most mail clients have no support for clip, overflow:hidden or background-clip.
Even an embedded image has very little support. Send a base64 image in HTML email
The best solution would be to render a copy of the image as you need it without any CSS trickery. This is the only real solution to your problem.
When coding emails, i seem to be getting broken templates in the Outlook web app preview pane, however when i double click the email (email opens in new window) it renders fine.
The text within td's have alot of spacing between lines, images aren't vertical-aligning correctly amongst other issues.
Does anyone know what causes this and how it can be fixed? I did read on-line that the preview pane wraps the email in its own and adds its own styling which affects the layout?
There are a few issues it could be, but I'd start with putting this in your style tag:
#outlook a {padding:0;}
Also, are you using tables? Make sure your <td>'s at least 19px high.
For images, make sure you have display:block; and the padding and margin zero'd out.
<img alt="" src="" width="" height="" style="margin: 0; border: 0; padding: 0; display: block;">
Beyond that, post some example code as it is hard to figure out the exact cause of each issue without seeing it.
I'm designing email template. Between some texts I need to put break lines. So far so good on most clients except outlook.com(on browser). It wraps my <br> inside a <p> which has big margin by default.
I have tried to use <br>, <td> with space, <td> with <span> and space inside and <td> with <p> with margin:0 and space inside. Each time i got my html wrapped in a <p>.
Why it wraps my html in <p> ??
I've never found the .ExternalClass hacks to be of any use. Outlook.com is very iffy in general about line-height and <p> tags as a whole, so I've found the best thing to do is remove all <p> tags from my emails just and put all text sections inside a <font> tag inside the <td>.
I ran a quick litmus test and wasn't able to reproduce your results, with either <br> or <br/> however you could just nest a table inside a <td>, don't define heights, and use multiple rows in that table to simulate breaks. I've found that it doesn't mess with my usual line-height rhythm.
Outlook has trouble rendering html emails correctly.
There is a little hack that might help you:
<style type="text/css">
.ExternalClass p (Or whatever, you can target pretty much anything here)
{line-height: 50%; margin:0;}
</style>
This will talk to outlook's native stylesheets and adjust those, since outlook applies the .ExternalClass class to your email.
Here is some important information on the subject: http://www.emailonacid.com/blog/details/C13/line_height_and_outlook.com
Many will say that all styling in html-emails has to be inline. This is true to an extent because some clients will strip the head and body tags from your email. But for those that don't, like outlook, it is a valuable space for work arounds.
Hope this helps.
The reason Outlook wraps everything in <p> tags is because it uses the MS Word engine to render html instead of a browser based renderer.
The p tags are unavoidable and the suggestions above are good ways to 'zero out' the unwanted margins. Outlook doesn't strip <style> tags, however some MS Exchange servers do (for security I assume), so if you are finding your style tags ignored in Outlook, try sending to a different domain email address (particularly a non corporate one) and you should find it will work as expected.
I also suggest never using <p> tags in email and using double <br> tags between paragraphs and <br> or <br> for top and bottom 'padding' within table cells.