I'd like to see if there's a way to customize an HTML e-mail based on the user's e-mail client.
I'm wondering if there might be a reliable way to do this with something sort of like a user-agent that would indicate that it's being viewed in Gmail, Outlook, etc. Then if there's a simple way to show and hide a few IDs that would contain client specific things sort of like a media query. I don't see any support for a user-agent media query so that seems like a stretch.
I know modern clients don't tend to support Javascript so that complicates things. TBH, I'd be really surprised if any of this can be done in the first place but figured its' worth asking.
For context, this message will tell people how to edit to their e-mail signature, which is different in each client. I'd rather have one dynamic set of instructions instead of including instructions for every client.
This is sometimes possible, but it changes because it's essentially based on bugs and non-official ways of targetting.
Check https://howtotarget.email/ for the latest ways of targetting different email clients.
For example, Outlook windows:
<!--[if mso | ie]>
<td>ALL OUTLOOK</td>
<![endif]-->
Also this bug works for targetting Yahoo and Gmail IMAP (one version of Gmail):
<!--Yahoo->
<p style="background:red;color:white;font-size:50px;">You are using Yahoo or AOL</p>
<!yahoo-->
Outlook.com (must be placed in a style block in the body, not in the head)
.olm-fragment-custom .your-class-name {
/* Replace this comment with your styles */
}
Related
For me this could just be a bit of nuance paranoia but is there any difference between how HTML Emails and HTML Email Signatures are created and/or rendered? Specifically, after doing some research I keep seeing HTML Email results coming up when I ask for HTML Email Signatures. Some search results do include signature.
From the research I've compiled I've seen that it's best to create HTML Email Signatures with the legacy layout method using the <table> element (Mainly to support Outlook), then I see it mentioned and used a lot less often that you can also use <div> for more flexibility with other email clients for both mobile and desktop and then also the use of "Ghost Tables" in combination with <div> to add support for Outlook and get the flexibility for other email clients.
For just HTML Emails the use of <div> is mentioned often and encouraged for flexibility across different email clients for desktop and mobile and <table> element is also mentioned often as a legacy way of laying out HTML Emails along with the use of "Ghost Tables" and <div>.
So I guess another way to ask this question is. Can the same code convention for HTML Emails (Use of <div> and <table>) be used to make HTML Email Signatures? Is there any code difference or can the same code be used for both?
When sending HTML emails, you send email X, and Outlook renders X one way, and Gmail renders X a different way. Outlook renders it according to it's largely print-based rendering engine (MS Word), and Gmail renders the same nice HTML according to it's largely web-based rendering engine. So everyone is happy, because Gmail doesn't care how much Outlook botched it. The render happens after sending.
But when setting up HTML email signatures, and if we use Outlook, the signature gets rendered according to Outlook's rendering engine before sending. Thus, you cannot send a responsive signature from Outlook (I'm pretty sure).
However, Gmail's tool to insert signatures is also relatively poor quality, and doesn't support <style> blocks, for example. Therefore it can be hard (but not impossible) to produce something responsive.
It ultimately depends on the quality of the editor used, as well as what the program subsequently does to it to 'clean' your code, as to what works (so, there is no exact answer for this question, sorry--may be why you've been downvoted). Usually, sending from a proper ESP is a lot smoother.
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 6 years ago.
Improve this question
When implementing an HTML template that will be sent in an email, what should I know? For example, I know most email clients do not download images by default. How do you get around that? What are other css/html implementations that are not supported?
The first thing as a rule of thumb is: When you code HTML emails, code like you're back in the 90s. That is: Table layouts!
Wrap everything in a Table widh
border="0" cellspacing="0" cellpadding="0"
CSS is supported in some mail clients, others fitler it completely. Some clients only allow inline-styles, not style tags. So it's best to still use <font> tags for text styling and the deprecated bgcolor attribute, and so on. Padding/margin around elements should not be generated using CSS padding and margin, but rather by using empty table cells that include a transparent 1x1px gif. Make sure to apply the height to the img tag as well as the td and if you really want to make sure, also the tr tag.
Things are getting better and better, with Gmail recently making changes that allow media queries for responsiveness, but that has not rolled out globally yet.
So with media queries not (yet) working everywhere and most people using mobile devices nowadays, it's not a bad idea to use a "mobile-first" approach and use media queries on larger displays to extend the layout. For Outlook, you can use conditional comments (as it doesn't support media queries either) to achieve the same:
<!--[if mso]>
<style>/* style block will only be used in MSO */</style>
<![endif]-->
where you are also able to target specific Outlook versions, for example the current Windows 10 Mail app is mso 16. You can use lte/gte/gt/lt just like in conditional comments used for old IEs in earlier times.
Speaking of Outlook: It's also a pain in the ... eye in some other areas. To force line-height and prevent some unwanted spaces, there are MSO-specific styles like mso-line-height-alt:0; and mso-margin-top-alt:1px;, I recommend reading up on these as well.
For column layouts, do not use float, but align="left" on each table that represents a column, except for the last table in a "row" (because that will cause problems with tables floating off the grid in Thunderbird).
In my experience, at least if you're starting a template from scratch, it's a matter of building, testing in clients (webmail, desktop and mobile devices), fixing, doing research about some client-specific things that don't look the way you'd like them, trying out some own attempts to fix it, and testing all over again.
Email clients and rendering engines
Email clients use different rendering engines to render HTML emails:
Apple Mail, Outlook for Mac, Android Mail and iOS Mail use WebKit
Outlook 2000/02/03 use Internet Explorer
Outlook 2007/10/13 use Microsoft Word (yes, Word!)
Web clients use their browser’s respective engine e.g. Safari uses WebKit, Chrome uses Blink
Update November 2016: Just recently Google announced support for embedded CSS and media queries in Gmail. This is HUGE for the email development industry. Now, as of September 2016, Gmail will support a slew of CSS properties which makes template development a lot easier for Gmail.
Litmus has a handy website dedicated to the current email client market share, based on their own internal stats (~1 billion emails).
font: http://www.leemunroe.com/building-html-email/
I suggest to you use and test these ones:
https://github.com/TedGoas/Cerberus
http://foundation.zurb.com/emails.html
http://litmus.com/
https://www.campaignmonitor.com/
I hope this helps you.
You can't link any external stylesheet, You cant use floats, some clients ignore background images. Your should check out foundation for email if you wish to use good looking html emails in your projects that most clients support. There are several default templates available that you can use or you can build your own custom designs.
There is a lot you need to know, but a few big ones that comes to mind are:
Use table based layout
Use HTML4 syntax
Use CSS2 syntax
Use inline css (style=) and do not include a style tag in the head
Use alt text for all images and use a background color as a fallback when the image hasn't been downloaded yet.
Those are just a few pointers, but I agree #Joseph Marikle, refer to the link he posted.
I'm utilising a technique for producing "responsive" emails which involves having two versions. One explicitly written for desktop and one written for mobile. Using a combination of conditional statements and CSS (mso-hide:all; display:none;) to hide the mobile version when in a desktop client and vice versa.
This works perfectly, and as intended. When I go to forward or reply to one of these emails, the styling breaks and the previously hidden 'mobile' version is shown. I've tried using inline styles (mso-hide:all; display:none;) on the table, as well as applying a class and using conditional comments to apply the same styling in a CSS fashion, but it's not working.
I'd show an example, but the work is rather sensitive.
Basically, I'm after a way to hide a table in Outlook and have it stay hidden when the email is replied to / forwarded.
Try wrapping your mobile version in <!--[if !mso]><!--> [tables] <!--<![endif]-->. That should prevent the mobile version from being interpreted by outlook and therefore being forwarded.
Forwarding html emails means forwarding the html that was already processed by the client, which if you look at an outlook processed html file, is horrendous. Filled with garbage MS code.
Most email developers (myself included) accept that you can't control forwarded emails, and therefore don't try to code so forwarding works properly.
Do they both have the CSS display values set inline? Are you overwriting the inline declarations with the !important tag in the media query?
Outlook often trashes the media queries (especially on forwarding), so if you have only one version visible inline as the default view, maybe that might work - which is what you should have for non-style tag clients like Gmail anyway...
I am using one of the MailChimp templates as a base for an email design, however I will not be using MailChimp to send the email.
The MailChimp template has around 330 lines of CSS in the head. Its beens a while since I last did HTML emails, but is this acceptable or do I have to use inline styles on the elements?
I wasn't sure if MailChimp had a script that turned all the styles into inline css, and if I had to do the same thing.
inline CSS is the most preferred for email templates, because not all email clients support CSS in head section
Here is Guide to CSS support in email
Gmail is now rolling out support for media queries and styles in the head. Using Campaign Monitor's Guide, all the major clients now support styles in the head. If you're wanting the broadest possible support it's probably safer to keep inlining styles, but if your users are all using the major clients it's now safe to start pulling the styles out.
Inline Styles is the way go to achieve a consistent look and feel across all email clients.
Also have a look at: http://coding.smashingmagazine.com/2012/03/13/techniques-overcome-poor-css-support-email/
Here is a great tool for taking an HTML-email document with styles in the header and moving them inline. Should save you a lot of time and effort.
http://premailer.dialect.ca/
It depends on which company you are using to send the email, certain companies, such as campaign monitor will automatically add your styles in the head to the corresponding elements marked with that class or ID. I would check whether the company provides that service before sending.
I would recommend using inline styling at all times, even if you are using a service that automatically adds it inline, just in case you ever decide to switch to another provider.
Generally the issues with using styles in the head come from gmail, hotmail and yahoo mail. These email clients tend to strip out the <head> tags. Some people claim that they are having positive results within these email clients with <head> styles, but if I were you I would play it safe and go inline.
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.