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.
Related
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!
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 9 years ago.
Improve this question
I'm designing an HTML template for an email newsletter. I've learned that many email clients ignore linked stylesheets, and many others (including Gmail) ignore CSS block declarations altogether. Are inline style attributes my only choice? What are the best practices for styling HTML emails?
I've fought the HTML email battle before. Here are some of my tips about styling for maximum compatibility between email clients.
Inline styles are you best friend. Absolutely don't link style sheets and do not use a <style> tag (GMail, for example, strips that tag and all it's contents).
Against your better judgement, use and abuse tables. <div>s just won't cut it (especially in Outlook).
Don't use background images, they're spotty and will annoy you.
Remember that some email clients will automatically transform typed out hyperlinks into links (if you don't anchor <a> them yourself). This can sometimes achieve negative effects (say if you're putting a style on each of the hyperlinks to appear a different color).
Be careful hyperlinking an actual link with something different. For example, don't type out http://www.google.com and then link it to https://gmail.com/. Some clients will flag the message as Spam or Junk.
Save your images in as few colors as possible to save on size.
If possible, embed your images in your email. The email won't have to reach out to an external web server to download them and they won't appear as attachments to the email.
And lastly, test, test, test! Each email client does things way differently than a browser would do.
Campaign Monitor have an excellent support matrix detailing what's supported and what isn't among various mail clients.
You can use a service like Litmus to view how an email appears across several clients and whether they get caught by filters, etc.
Mail chimp have got quite a nice article on what not to do. ( I know it sounds the wrong way round for what you want)
http://kb.mailchimp.com/article/common-html-email-coding-mistakes
In general all the things that you have learnt that are bad practise for web design seem to be the only option for html email.
The basics are:
Have absolute paths for images (eg.
https://stackoverflow.com/random-image.png)
Use tables for layout (never thought
I'd recommend that!)
Use inline styles (and old school css
too, at the very most 2.1, box-shadow
won't work for instance ;) )
Just test in as many email clients as you can get your hands on, or use Litmus as someone else suggested above! (credit to Jim)
EDIT :
Mail chimp have done a great job by making this tool available to the community.
It applies your CSS classes to your html elements inline for you!
In addition to the answers posted here, make sure you read this article:
http://24ways.org/2009/rock-solid-html-emails
The resource I always end up going back to about HTML emails is CampaignMonitor's CSS guide.
As their business is geared solely around email delivery, they know their stuff as well as anyone is going to
'Fraid so. I'd make an HTML page with a stylesheet, then use jQuery to apply the stylesheet to the style attr of each element. Something like this:
var styleAttributes = ['color','font-size']; // all the attributes you've applied in your stylesheet
for (i in styleAttributes) {
$('body *').css(styleAttributes[i],function () {
$(this).css(styleAttributes[i]);
});
}
Then copy the DOM and use that in the email.
I find that image mapping works pretty well. If you have any headers or footers that are images make sure that you apply a bgcolor="fill in the blank" because outlook in most cases wont load the image and you will be left with a transparent header. If you at least designate a color that works with the over all feel of the email it will be less of a shock for the user. Never try and use any styling sheets. Or CSS at all! Just avoid it.
Depending if you're copying content from a word or shared google Doc be sure to (command+F) Find all the (') and (") and replace them within your editing software (especially dreemweaver) because they will show up as code and it's just not good.
ALT is your best friend. use the ALT tag to add in text to all your images. Because odds are they are not going to load right. And that ALT text is what gets people to click the (see images) button. Also define your images Width, Height and make the boarder 0 so you dont get weird lines around your image.
Consider editing all images within Photoshop with a 15px boarder on each side (make background transparent and save as a PNG 24) of image. Sometimes the email clients do not read any padding styles that you apply to the images so it avoids any weird formatting!
Also i found the line under links particularly annoying so if you apply < style="text-decoration:none; color:#whatever color you want here!" > it will remove the line and give you the desired look.
There is alot that can really mess with the over all look and feel.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
What are the proper practices in designing an email with a reasonable expectation that it will show up correctly for Outlook 2003, 2007 and in a webmail client? I'm subscribed to various email newletters and have viewed the source on them and have seen some of them have 2000 lines of HTML&CSS along with IF statements I've never seen before (I assume related to determining versions of outlook).
Is there a tool either free or commercial that can be used to create the markup? Is there a standard pattern on how to apply these huge stylesheets I've seen?
Designing for email is a nightmare, due to Microsoft's adoption of the Word HTML engine for newer versions of Outlook. There's no tool that I know of, but this guide will give you a helping hand when trying to decipher what client supports which CSS:
Guide to CSS support in email clients
Oy. Such awful answers.
See? This is what happens when everyone decides that using tables instead of css is some kind of taboo. Everyone's limiting themselves with such CSS arrogance and elitism. When all one has is a hammer, everything looks like a nail. Unbelievable.
One poster wrote: "That was my starting point and even that isn't reliable, even a simple single column table with a fixed width gets messed up where the table cells expand for no reason past the width."
Fixed width is what got you in trouble. A 600-pixel fixed-width table is obviously going to be wider than a 400-pixel email viewing window/area. It doesn't expand wider, it IS wider. [sheesh]
There is no way to predict how wide will be the recipient's email viewing window/area. So, create a single table, but set it's width to 100%, not a certain number of pixels. And set its height to "auto." Make its padding nice and wide... 7 to 10 pixels, minimum.
Then just do everything within that table as you normally would, but stick with vanilla HTML4, avoiding XHTML, DHTML, XML, java, javascript, etc., etc. Just HTML4. No CSS, either. Just HTML4. Period.
Use images that are on a web server somewhere that can be linked to using normal http:// URLs, and then just link to them using normal img tags, placing the entire URL of the image (including the http:// part) between the quotes, as in...
src="http://www.website_url.com/filename.jpg" (or .gif or whatever)
...and avoid using the "alt" feature or anything fancy.
If you want to strictly control font size, then don't hesitate to use the "span" tag since it will work in nearly every email client... just dont get too fancy with it.
Also don't make your images too big... especially, don't make whatever is the "header" or top image too wide. Setting the table width to auto won't help much if the graphic remains 600 pixels wide and the receipient's email viewer is 400 pixels wide. Use a graphic that will nest nicely in the upper-leftmost corner of the email message; and use fairly small photos and other graphics.
Do all that and you should find that the email will look the same in pretty much every email client. Double-check by using...
http://litmusapp.com/email-previews
...as another poster, here, suggested.
Hope that helps.
There are definitely some best practices in creating reasonably cross-client compatible emails.
2 of the most important concepts to remember are:
Only use inline CSS. This will save you many headaches as Gmail and many other email clients choke on having CSS in a <style> tag.
As many people have said already, tables are the way to go for sizing elements (instead of CSS).
I actually just wrote post on this topic with some best practices, if you're interested:
http://www.versapay.com/developer-blog/the-art-and-science-of-email-rendering-across-email-clients/
I would recommend a preprocessor based framework like Foundation for Emails.
It's extremely difficult to make emails that work across all the clients because they use different rendering engines from web browsers, where the design was likely developled. Try using LitmusApp's email testing service, which will give you screenshots in how your email will appear in different email clients.
Keep the width fairly narrow (~600px at a guess).
Use tables rather than CSS divs.
Make sure it works in IE6!
HTML cannot be successfully implemented in email for three reasons.
1) HTML is designed to work for the HTTP protocol (web) only and not SMTP protocol (email). This is clear in that the head of an HTML document supplies data relevant to the processing of the document in accordance with a transfer over HTTP. Since HTML supplies no conformity to the conditions supplied by the SMTP protocol it is on its face in compatible. As of this time there is no standard of any kind for describing the format of content in email.
2) HTML is not a presentation language. HTML is intended to supply structured meta-data to content and is never intended for presentation. HTML is only used in email for presentation, and as such is often abused and used in complete violation of the standards.
3) A single document in email can have multiple authors each with independent header information. Such a document is called an email thread. HTML has no such convention. When HTML is supplied in email it may look fine to the initial user who receives it, but when replied or forwarded it will look like crap and fail to do its job, which is likely not doing anyways. To my knowledge Mail Markup Language is the only markup language containing features to address and serve multiple author contributions to a single markup language document without conflict as is necessary to support an email thread accurately.
Those three reasons are why HTML is completely incompatible with email and is not capable of being successful.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
(I'd like this to be the definitive community wiki. I seeded it from my own answer to this question.)
Specify Everything
A lot of cross-browser issues amount to this: you didn't specify something, and different browsers make different assumptions. Therefore:
Declare a valid doctype
Your doctype tells the browser what rules you'll be using in your code. If you don't specify, the browser has to guess, and different browsers will guess differently.
In my experience, a "strict" doctype makes IE behave better (enables things like CSS :hover selectors on divs in IE7).
This article gives good background on doctypes.
Use Web standards
Avoid browser-specific markup, or only use it when its failure in other browsers won't be significant to the site experience.
Validate your HTML and CSS
You don't have to get everything perfect, but validation is good feedback. As Jeff said:
Knowing the rules and boundaries helps you define what you're doing, and gives you legitimate ammunition for agreeing or disagreeing. You can make an informed choice, instead of a random "I just do this and it works" one.
Imagine you opened a paragraph tag and never closed it. If you then open a list tag, did you mean it to be inside the paragraph or not? Validating will help you catch that, close the tag, and eliminate ambiguity.
Consider a CSS Reset
Different browsers assume different baseline CSS rules. You can help them all to act the same by explicitly ironing out the differences up front. Eric Meyer, who wrote CSS: The Definitive Guide, uses this reset. Another popular choice is YUI Reset CSS.
Use a Javascript library for DOM interactions
Whenever your Javascript needs to work with elements on your page, it's best to use a library like jQuery, Prototype, or MooTools. These libraries are used by many thousands of developers, and they take most of the inconsistencies between browsers' interpretation of Javascript, deal with those internally, and give you a consistent set of commands that just work. Trying to find and work around all these inconsistencies yourself is a waste of time and likely to create bugs.
Test in multiple browsers, deal with IE last
Test in multiple browsers as you go. Generally, you'll find that non-IE browsers behave similarly and IE is a special case - especially if you follow the advice above. When necessary, you can add IE hacks in a separate stylesheet and only load it for IE users.
Quirksmode.com is a good place for hunting down random browser differences.
Browsershots.org can help show how your page will be displayed in an assortment of browsers and operating systems.
Fail Gracefully
No site will look perfect in every browser that exists. If a user doesn't have Flash, or Javascript, or advanced CSS, etc, you want your site to be usable anyway. Design with that in mind:
Check the bare HTML
Try loading your site with bare HTML - no styles, no scripts. Are menu options available? Does primary content precede secondary content? Is the site usable, even if ugly?
Consider test-driven progressive enhancement
Described in this article, this technique uses javascript to check if a browser has a given capability, such as support for a given CSS property, before using it on the page. It is unlike browser sniffing because it tests for features rather than a specific browser.
Use a library like jQuery abstract away the differences in the DOM, AJAX and JavaScript.
Make sure you're keeping HTML, CSS and Javascript in separate files as much a possible. Mixing structure, presentation and behavior in your HTML file just makes finding and fixing problems harder.
Use Firebug in Firefox for:
Debugging/stepping through your JS.
Seeing how your stylesheets are being interpreted and hacking them up on the fly to see how to fix your problem.
See how many calls you are making for remote resources and how long they take.
Profile your code.
Chrome and IE8 have similar tools built-in that can be used for the same thing.
Opera and Safari (and IE) have Firebug Lite.
Use CSS Reset on start of your stylesheet...
You can get one here...
Validate your code by w3c ...
You can validate your code here by page link or simply copy paste page element
My #1 rule is use a strict doctype. HTML or XHTML is fine, but using the strict doctype removes pretty much every browser quirk there is, especially in IE7+.
Imagine you opened a paragraph tag and never closed it. If you then open a list tag, did you mean it to be inside the paragraph or not?
Actually you can't put any other block tags inside a <p> tag, that's why the spec allows you to omit the closing tag. If you start a list without closing a paragraph, then the paragraph is implicitly closed. And the validator won't complain.
That's not to say you shouldn't close tags, because it generally makes code easier to skim (you don't need to remember the above rules).
Consider programming you web-site's UI using Google Web Toolkit. With GWT you write all code in Java programming language which GWT then cross-compiles into optimized JavaScript that automatically works across all major browsers.
I think using best practice is the way to go, progressive enhancement is designing with the user in mind and needs to be done with all designers. I believe that a lot of testing on browsers is a good way to ensure proper content is being displayed, many developers over look this.
I have an app that reprocesses HTML in order to do nice typography. Now, I want to put it up on the web to let users type in their text. So here's the question: I'm pretty sure that I want to remove the SCRIPT tag, plus closing tags like </form>. But what else should I remove to make it totally safe?
Oh good lord you're screwed.
Take a look at this
Basically, there are so many things you want to strip out. Plus, there's stuff that's valid, but could be used in malicious ways. What if the user wants to set their font size smaller on a footnote? Do you care if that get applied to your entire page? How about setting colors? Now all the words on your page are white on a white background.
I would look into the requirements phase again.
Is a markdown-like alternative possible?
Can you restrict access to the final content, reducing risk of exposure? (meaning, can you set it up so the user only screws themselves, and can't harm other people?)
You should take the white-list rather than the black-list approach: Decide which features are desired, rather than try to block any unwanted feature.
Make a list of desired typographic features that match your application. Note that there is probably no one-size-fits-all list: It depends both on the nature of the site (programming questions? teenagers' blog?) and the nature of the text box (are you leaving a comment or writing an article?). You can take a look at some good and useful text boxes in open source CMSs.
Now you have to chose between your own markup language and HTML. I would chose a markup language. The pros are better security, the cons are incapability to add unexpected internet contents, like youtube videos. A good idea to prevent users' rage is adding an "HTML to my-site" feature that translates the corresponding HTML tags to your markup language, and delete all other tags.
The pros for HTML are consistency with standards, extendability to new contents types and simplicity. The big con is code injection security issues. Should you pick HTML tags, try to adopt some working system for filtering HTML (I think Drupal is doing quite a good job in this case).
Instead of blacklisting some tags, it's always safer to whitelist. See what stackoverflow does: What HTML tags are allowed on Stack Overflow?
There are just too many ways to embed scripts in the markup. javascript: URLs (encoded of course)? CSS behaviors? I don't think you want to go there.
There are plenty of ways that code could be sneaked in - especially watch for situations like <img src="http://nasty/exploit/here.php"> that can feed a <script> tag to your clients, I've seen <script> blocked on sites before, but the tag got right through, which resulted in 30-40 passwords stolen.
<iframe>
<style>
<form>
<object>
<embed>
<bgsound>
Is what I can think of. But to be sure, use a whitelist instead - things like <a>, <img>† that are (mostly) harmless.
† Just make sure that any javascript:... / on*=... are filtered out too... as you can see, it can get quite complicated.
I disagree with person-b. You're forgetting about javascript attributes, like this:
<img src="xyz.jpg" onload="javascript:alert('evil');"/>
Attackers will always be more creative than you when it comes to this. Definitely go with the whitelist approach.
MediaWiki is more permissive than this site; yes, it accepts setting colors (even white on white), margins, indents and absolute positioning (including those that would put the text completely out of screen), null, clippings and "display;none", font sizes (even if they are ridiculously small or excessively large) and font-names (even if this is a legacy non-Unicode Symbol font name that will not render text successfully), as opposed to this site which strips out almost everything.
But MediaWiki successifully strips out the dangerous active scripts from CSS (i.e. the behaviors, the onEvent handlers, the active filters or javascript link targets) without filtering completely the style attribute, and bans a few other active elements like object, embed, bgsound.
Both sits are banning marquees as well (not standard HTML, and needlessly distracting).
But MediaWiki sites are patrolled by lots of users and there are policy rules to ban those users that are abusing repeatedly.
It offers support for animated iamges, and provides support for active extensions, such as to render TeX maths expressions, or other active extensions that have been approved (like timeline), or to create or customize a few forms.