I am wondering if shorthand CSS coding is allowed for HTML Emails.
I know the CSS allowed is very limited but I know padding for example is allowed but would this be allowed:
padding:0 4px 0 6px;
The CSS that is allowed in an email is what the receiving email client understands. There are many different email clients. Not all of them even render HTML email (though virtually all do these days), but even where they do render HTML, their rendering engines will all be different from one another, in the same way as web browsers. But unlike web browsers, people don't always change their email client if they're not happy with the way it renders.
So you should expect your email to be read using virtually any kind of email program, including ones which don't render HTML at all, and those which render it, but using an IE4-vintage rendering engine.
That said, I would expect virtually all email clients to correctly interpret the CSS padding style.
You may get some with quirks-mode box models, which will cause your box sizes and positions to be wrong, but they should still interpret the padding correctly within their own set of rules.
One thing I would say is that you should ensure all your CSS code is embedded in the HTML. Put a big <style> tag at the top of your document, rather than a <link> tag with an external reference. The reason for this is that 1) some users may view your email when they're offline, in which case they won't be able to load an external stylesheet, and 2) some email clients may be set to block loading external files from within an email for security reasons, even if the user is online. If your styles are all included in the main body of the email, this won't be a problem. (you may still have the same issue with graphics, but that's a whole different topic of discussion)
I have never had a problem doing 'shorthand' like that, so long as all of the values are provided.
Technically, padding:0px 4px; should work such that top & bottom are 0, and left & right are 4, but not all email clients will honor that (I'm talking to you, Outlook 2007/2010!) so you need to include all four for margin, padding, border etc.
In case this is still of interest I have been looking into this lately. Some mass mail company clearly state that some applications like font (at least) are not rendered well on some email clients.
http://www.campaignmonitor.com/resources/will-it-work/guidelines/
Actually after reviewing a few email sources of templates (Mailchimp, Campaign Monitor, etc) they all consistently avoid them so my conclusion so far is been to do so as well.
In any case more important than shorthand or not is the fact that most CSS styles need to get "inline" of elements as many (Gmail included) ignores them if defined on the head.
As a simple solution I tend to use basic styles on the body element and on a containing table surrounding the content (as body styles also get removed by some clients).
In a simplest form you can set styling for each element like this:
<p style="padding:0 4px 0 6px;">your contents</p>
Yes.
And, as with any "webpage", what the user actually sees is completely up to the "browser" (or HTML-capable email client).
You could have simply tried it to find out.
Also, I recommend not being obnoxious by splashing graphics and colours all over emails. :(
Related
I have HTML template completely written with div, a, img, button elements with inline CSS styling. It renders perfectly in HTML editors but not in Email clients. Should it be completely written in table form for Email clients? Here is my code:
Look it on JSFiddle
I believe your particular question is dependent on which email-client you are targeting. It would be helpful if you could specify which email-client you are looking to use, as well as which parts of your html are not working, because certain email-clients may not support certain parts of your code.
For example, as defined here,
Outlook has the following problems for rendering HTML:
Outlook does not “understand” HTML bulleted list tags
Outlook uses Times New Roman as the default font
Outlook may add a page break to an email if it exceeds 1800px
Outlook cleans up paragraph and margin spacing
Outlook does not support background images
Which you may be able to fix by using specific techniques, such as, as you mentioned, wrapping with tables. I found a link here that may be helpful if you are trying to resolve the rendering on Outlook.
If there is another specific email-client you need to target, there should be posts on stack overflow or on the web for resolving them as well.
Good luck!
You do have to use tables in email HTML and then use CSS and formatting to mask it. Here's a handy guide you can use for email HTML.
I'm the author of an email client and one of things I'm in the process of doing is adding support for HTML editing. The editor itself it build upon a HTML rendering control that I've written from scratch, however it supports most HTML and CSS fairly well. The issue I'm having is formatting the reply to HTML email with the user's reply template, which is also HTML (with a different style sheet). So cleanly merging two HTML documents with their own styles without either of them being messed up by the other document's styles.
When the user replies to a HTML email, I parse out the content of the tag and put it into a that forms part of the reply. That div's style shows a line down the left margin to inform the user that it's quoting the original email. Gmail does the same thing. Anyway the styles from the HTML block as saved separately and then insert into the head part of the new document.
What happens of course is that if the original email defined a style for say a link, that style affects all the links outside the original quoted area. So things like my signature at the bottom and the From/To header rendering that is part of the reply template all get that styling from the source HTML.
I'm wondering if there is an easy straight forward solution to containing all the original styles to just the quoted part of the document? Something like namespacing? Or limited scope styling?
The solution I've come to is to add all the incoming styles from the multiple documents to a global style sheet. Styles are matched by first checking the count of properties is the same, then enumerating each property and comparing it's value. This basically gives the software a minimum number of styles to correctly render the content. It could be really slow in a pathological case but so far it's working well in practice.
As an aside, recently I've noticed a lot of email clients striping all the style out of replies. Which to be honest seems like the cheap and nasty solution to the issue. Even if it does give a consistent look.
What are current trends with html email?
Looking into repsonsive design html email I came across this article on campaignmonitor.
It seems to mix css #media queries and other css in style blocks rather than inline styles, with old school table layouts.
Surely, if an email client is capable of processing css it knows what to do with a div? Or is the table just as a fallback for those that still can't? And the media queries and block css extra sweetness for those that do?
I realise that email clients don't change as rapidly as web browsers but are tables still the best way forward?
I'm sure this question has been asked loads of times before, but I'm looking for modern trends.
Perhaps this should be another question, but I also notice that the article mixes element.class and element[class="classname"] declarations - the last of which I've only ever used with input[type="value"] before. Why the square brackets for classes?
Recently my company was changing their emails layout. First we decided to test the compatibility of different email clients with the newest html/css standards. However, during the coding process we encountered many problems with proper rendering which forced us to turn back to table-based layout.
We also used #media-queries and more sophisticated styling for clients able to understand them, but unfortunately tables are still the way to go if you want to support popular mail clients. It's a pity that so many business clients use old Outlook or similar.
After the work was done, we were testing our layouts with Campaign Monitor Tester but it wasn't enough so we had to test many clients manually.
Summing up: If I was to code an email layout now, I'd go with tables and inline styles.
Edit: Brackets-notation is correct, but I don't see the point. Moreover in this example it will only match elements with exactly one class named classname. It won't match <p class="classname othername">. If there's no other arguments for using it here, I'd go with standard dot notation (.classname).
It should be noted that you need to inline all your css for maximum compatibility. Campaignmonitor has a tool that auto inlines it for you, so keep that in mind when reading their suggestions.
Reason css needs to be inlined is because of web-based clients like gmail and (i think also) yahoo stripping out the style declarations (as well as everything outside the body tags) to ensure it doesn't mess up with their webpage. Media queries can't be inlined, so even though it is a current trend to make responsive emails, note they won't work in gmail.
Still work in tables because there are inconsistencies with different email clients, particularly how they handle different css properties. One of the major reasons emails are 'stuck in the past' is because of Outlook which uses the MS Word render engine. Outlook is still the most popular email client particularly with B2B.
Hope that info helps!
I'm writing a webmail product and some emails have body css that changes the background ... so when I Html.Decode() that emailbody, it's altering the CSS of the entire page.
Is there a good way to contain that problem?
You can make your CSS more specific than the email's rules. For example:
body.body is more specific than .body or body
Any styles in body.body that clash with those in the lesser examples above, will override. But to stop the styles merging together, you'll need to define every single style.
Alternatively you can go with rewriting the CSS in the emails, which is the way most webmail/desktop email clients go these days, one way or the other. If you prefix all the rules with #emailMessage, for example, and place the email inside a <div id="emailMessage"></div> tag, all the styles in the email will only apply inside that namespace.
Using an iframe to display emails only introduces more problems based around accessibility, etc etc. Good luck.
The answer to your question is probably "iframe", but in your specific situation, writing a webmail client is going to introduce you to a wonderful new hell called "stripping css from possibly extremely invalid html generated by a large variety of clients that all have their own ideas about what kind of html should be allowed in an email".
Good luck!
A common way is to use iframe, although i'm not sure this is applicable for your problem.
Basically it loads a different html page inside another page. Which makes it independent, but it does mean you have 2 pages to display one email.
http://www.w3schools.com/TAGS/tag_iframe.asp
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
What guidelines can you give for rich HTML formatting in emails while maintaining good visual stability across many clients and web based email interfaces?
An unrelated answer on a question on Stack Overflow suggested:
http://www.campaignmonitor.com/blog/archives/2008/05/2008_email_design_guidelines.html
Which contains the following guidelines:
Place stylesheet in <body> instead of <head>
Some email clients will strip CSS out of the head, but leave it if the style block is (invalidly) in the body.
Use inline styles where ever possible
Gmail will strip any stylesheet, whether in the <head> or in the <body>, but honor inline styles assigned using the style="" attribute
Return to tables
Email standards have actually taken a giant step backwards in recent years thanks to Outlook 2007 using the Microsoft Word rendering engine. Unlearn most of what you learned about positioning without stylesheets.
Don't rely on images
Most clients and most web based email clients will not display images unless the user specifically requests them to be displayed.
I also have a few "unconfirmed" truths that I don't remember where I read them.
Don't use more than two levels of nesting in tables
Is this true. What is likely to happen if I do? Is there any particular client/clients that choke on this?
Be careful of nesting background images in cells/tables
As I understand you may encounter situations where the background image is applied in the descending table/cell completely anew, and not just "shining through". Again, true or not? Which clients?
I would like to flesh out this list with more guidelines and experiences from the trenches.
Can you offer any further suggestions?
Update: I'm specifially asking for guidelines for the design part in HTML and consistency there of. Questions about general guidelines for avoiding spam filters, and common courtesy are already on SO.
It's actually really hard to make a decent HTML email, if you approach it from a 'modern HTML and CSS' perspective.
For best results, imagine it's 1999.
Go back to tables for layout (or preferably - don't attempt any complex layout)
Be afraid of background images (they break in Outlook 2007 and Gmail).
The style-tag-in-the-body thing is because Hotmail used to accept it that way - I'm pretty sure they strip it out now though. Use inline styles with the style attribute if you must use CSS.
Forget entirely about float
Remember your images will probably be blocked - use background and text colour to your advantage - make sure there is some readable text with images disabled
Be very careful with links, be especially wary of anything that looks like a URL in the link text - you will anger 'phishing' filters (eg www.someotherdomain.tld is bad)
Remember that the "fold" on webmail clients tends to be extremely high up the page (on a 1024x768 screen, most interfaces won't show more than a hundred pixels or so) - get your identity stuff in right at the top so the recipient knows who you are.
Recent version of outlook have a "portrait" preview pane which is significantly narrower than you may be expecting - be very wary of fixed-width layouts, if you must use them, make them as narrow as you can.
Don't even think about flash, Javascript, SVG, canvas, or anything like that.
Test, a lot. Make sure you test in a recent Outlook (things have changed a lot! It now uses Word as its HTML rendering engine, and it's crippled: Word 2007 HTML/CSS support). Gmail is pretty finicky also. Surprisingly Yahoo's webmail is extremely good, with nice CSS support.
Good luck ;)
Update to answer further questions:
Don't use more than two levels of nesting in tables
I believe this is an older guideline pertaining to Lotus Notes. Nested tables should be okay, but really, if you have a layout that's complicated enough to need them, you're probably going to have trouble anyway. Keep your layout simple.
Be careful of nesting background images in cells/tables
This may be related to the above, and the same applies, if you're getting that complicated then you will have problems. Recent versions of Outlook don't support background images at all, so you'd be best advised to forget about them entirely.
Always use multipart mime and provide a plain text alternative.
The folks behind Campaign Monitor also started a Email Standards Project web site with a lot of good information.
Take a look at this boilerplate, it is like html5boilerplate, but for emails:
http://htmlemailboilerplate.com/
I think this is lower level than the question you are asking, but if you really want an html email to be correctly viewed by as many clients as possible, make sure it's using valid MIME. In particular, for an email to be considered as valid MIME, the headers MUST (in the RFC sense of the word) contain both of these headers:
MIME-Version:
Content-Type:
Very strict clients will display your HTML as raw text if one or the other of these is missing. You'd be surprised how many large online vendors who should know better have screwed this up (notably, I've gotten HTML emails w/ missing MIME-Version: headers from Amazon and the ACM in the past)
Background images are not reliable.
Practically a no-brainer, but no javascript.
Use an editor that lets you send the current file/buffer as an email, or at the very least, find a program that would let you send the contents of a file as an HTML email. do not test your emails by copying the HTML, and pasting it into outlook (or any other mail program for that matter).
Three words of advice: test, test, test.
Check out LitmusApp.com's email testing service. You send them a message and they render it in a bunch of clients and show you screenshots of the results. It's not perfect, but it's pretty good.
(Lotus Notes prior to 8.0 really, really stinks for HTML mail, by the way)
Also, beyond just inline CSS styles, I recommend switching to tags wherever possible.
Embed your images, don't link to them.
This is bad :
<img src="http://myserver.com/myImage.jpg" alt="Lolkat"/>
This is good :
<img src=cid:myImage/>
Yeah, it looks weird but check out this guide regarding embedding images in emails.
If you're including a style block don't begin any new line with ".classname" or "." anything. Put a brace or something before the period. If you don't do this some web mail systems will not properly display your style sheets.
Many people have incorrectly assumed they cannot use CSS blocks in emails because of this behavior... IIRC "." is the body delimiter for SMTP. Systems will tend to escape in their mail stores to prevent the contents of one message from being misrecognized as a new message. The way this is handled tends to break any style starting on a new line with a period.