I'm trying to build an HTML email using DIVs instead of tables, and I'm quite new to CSS.
What I'm trying to achieve would look something like:
******************* XXXXXXXXXXXX XXXXXXXXXXX
* image here * XXXXXXXXXXXX XXXXXXXXXXX
******************* XXXXXXXXXXXX XXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
X = Some Text
1 image +
5 lines of text
Any ideas?
Emails is one of those places where whatever notion you have of good practices for layout should be thrown out the window. Many, many email providers filter out any CSS rules you throw in, so the best thing to do if you absolutely want a "complicated" layout in your email is to stick to old school tables, as they will bring you the closest to your emails being delivered properly to all your users.
Resources that may be of use to you:
The Email Standards Project (includes a list of clients and their supported/unsupported features - Gmail and Outlook 2007 are likely to be the nasty ones)
Campaign Monitor's resources page (has a nice CSS support matrix)
Campaign Monitor's automatic e-mail tester (paid service)
Well-designed emails are super tricky. In general, you can assume that email clients will not pull in externally linked CSS files (or at least not properly) and that they will perform some manipulation of your HTML (usually just attributes and adding in some extra markup). But this is not a place to uphold the best of all practices, and certainly nowhere to "learn" about good markup or CSS design.
In general, HTML emails follow the worst rules of web design. The two big things to keep in mind are:
Use HTML tables for complex layout (anything with columns)
Use inline CSS styles (even embedded CSS styles -- those put in the head of the document -- may not be rendered correctly in most email clients)
It is also a good idea to push your clients to abandon the fancy email newsletter in favor of a well-designed text-only email that is more accessible on a wider variety of platforms. Cite the rise of mobile devices used for email access as a major reason to do so, although the benefits for the end-user are far reaching.
This SitePoint article sums up the approach pretty well.
CSS support in email clients is not very standardized. It's generally accepted to use html 4 attributes in lieu of CSS for your HTML emails.
As an employee for a large ad agency who does a LOT of html emails for big name clients, I will say that they are messy!
Use nested tables for layout. I even use white (or the email background color) 1x1 pixel spacer images for almost all gaps and stuff (as padding and margins won't always work correctly.)
Like some people have said before, inline styles are the only ones you can count on, but even with those, 'background-image' will get ignored alot.
As long as the client hasn't requested any sort of dynamic text, I use images for most of my text as well, to avoid any font or sizing problems.
Hell, if you can, just cut the thing into a few big images and send it out.
Everyones response has been great. Campaign Monitor along with http://www.email-standards.org are the best resources out their right now.
However, what I was told by a fellow developer when making my first html email - "code like its 1997".
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!
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. :(
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.
My web-app has to deliver db-generated content by email. The HTML need not include javascript but _does have to include images and CSS.
It's a safe bet that most users will be viewing this in Outlook. Are general guidelines different for html destined for email vs. IE?
Outlook doesn't have a quite good reputation about HTML mails -- see Microsoft to ignore web standards in Outlook 2010 - enough is enough, for instance.
But it's not the only email client with problems, actually : generating an HTML e-mail generally means doing some things differently than for a webpage...
For instance, you can take a look at this article : Ensuring your HTML Emails Look Great and Get Delivered. A few points it make are :
use inline CSS
use tables and basic layout
Well... quite the contrary of what is said for webpages, isn't it ?
And a piece of advice : always test your email in as many clients (both desktop-based, like outlook, thunderbird, ... and web-based, like yahoo, hotmail, gmail, ... ) as possible !
Absolutely. It's virtually impossible to use CSS layout techniques in HTML emails. So...code like it's 1998.
Use tables. It's painful, but it's the only surefire way to get HTML emails to display properly and consistently. Make sure you set cellpadding, cellspacing, and border on every single table. Nest them if you must. colspan and rowspan are your friends. Use shim .gifs in empty cells. If it's a bad practice for regular webpages, you should probably be using them in e-mails.
Don't design for anything wider than 600 pixels.
Since webmail services' CSS can be overwritten by CSS inside of the e-mails, they tend to disable it. Inline CSS is smart. Font tags are smarter.
Forget about doctypes, <html>, <body>, or <head>.
Don't rely on background images - if you must use them, have a background color backup.
Avoid spammy-sounding terms. Don't talk about Viagra, porn, or knockoff watches - it'll probably get spam-filtered.
Send text-only alternative using the "Multipart/Alternative" MIMEtype.
Debugging is a bear. The testing list we use at my place of business: Outlook 2003, Outlook 2007, Outlook Express (from XP), Thunderbird Mac and Windows, Eudora, Mail.app, Entourage, Gmail, Yahoo! Mail, AOL, AOL Webmail, and Hotmail. Webmail clients tested in both IE6 and the latest Firefox version. It may be worth cooking up a script to automatically send emails to test addresses at all the services for testing.
Good info about specific support at Campaign Monitor's site. They also have more practical guidelines. And here's a list of e-mail client usage.
In Outlook 2007, it took a huge step backward: http://www.sitepoint.com/blogs/2007/01/10/microsoft-breaks-html-email-rendering-in-outlook/
Instead of using IE for the rendering engine, it now uses Word. Only the most basic HTML is supported well or at all.
http://www.campaignmonitor.com/blog/post/2533/a-guide-to-css-support-in-emai-2/
Email user agents, in general, tend to diverge from the standards for CSS and HTML pretty significantly for good reason. Some email user agents, such as Thunderbird, claim to have full CSS support in email, but to my knowledge no email user agent fully supports the HTML standard.
HTML is designed for the web, specifically, HTTP transmission. It contains header definitions, all the bits that fall under the <head></head> tags, that are intended to operate under HTTP transmission. HTML is a markup language, which is a document of structured data. Markup languages are not presentation languages, but the only point of using HTML in email is for presentation. As a result HTML is not functional in email and is hardly accessible.
In HTTP a user requests a resource from a server and a server responds with that resource. The author of the document provided from the server is somebody who is able to author documents on/to the server. A resource provided by HTTP has only one author.
In email a document can be written to by many different users opposed to HTTP. A document does not originate at a server. Since a document does not originate at a server or a known single user markup languages and CSS experience containment and scope problems. This means HTML and CSS in email are entirely incompatible to the concept of an email thread where multiple people are contributing to a document, because the CSS does not understand that it is supposed to be constrained to a single instance of communication.
Due to these incompatibilities that were never intended to exist and are not intended to ever be corrected Microsoft is entirely correct in supporting as little or as much HTML in email as they want. There is no standard addressing this, so there is no violation. The violation is using HTML in email to begin with.
My advise is to wait until Mail Markup Language is adopted. If we are all very lucky one particular user agent vendor may announce adoption of Mail Markup Language in the near future. To my knowledge Mail Markup Language is the only functional markup language specification to address the requirements of email threads at this time.
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.