I have been tasked with changing some email templates (password resets, etc.). The new templates I have been given are simple, but include a few small images for aesthetic reasons. What are the best practices for including these in emails?
As I understand it, many email providers block images by default due to privacy and tracking concerns (tagging users using unique image URLs for each recipient and waiting for their browser to load the resource). Would using a data URI for images be an effective solution to this issue, or are these blocked too? (And if so, I would love to know why!)
Aside from the fact that really old browsers (IE7-) do not support this format, are there any other reasons not to use it? As far as I understand it, when it comes to email you need to be as simple and transparent as possible, and I worry that doing something a little bit unusual like this could set off alarm bells in the spam filters. Is this concern justified?
Foreground Images (JPG, PNG, GIF) are universally understood in all major email clients. Markup is the same as on a web page (<img src="">). Things like background images, SVG, or data URIs work in some clients but not all, it's best not to rely on these as a way to display essential images. SVG support in email clients.
Some email clients block images by default, but can be downloaded is user clicks a button. Here is a good rundown on image blocking in email clients.
Related
I wonder if it is possible to create multi-paged e-newsletter. I know that the email clients are in general very restrictive (for a good reason of course) so one has to use plain table-based html for design and even images download has to be manually approved not to mention scripts. But maybe...with the help of html5 or other advanced technologies it could be possible to include the additional pages to the attachement and use them somehow. What do you think?
Your best chances are creating "read more..." buttons that link to a webpage.
If you would want to have multipage newsletters, there are various options:
Frames
Iframes
Use of JavaScript
Unfortunately, all of these options are sent straight to the spambox.
Even if there would be a HTML5 tag or element-only option, eg. a slider, most e-mail clients won't support these new features for the next billions of years. Webdev's complain about IE, but e-mail clients are much, much worse.
Generally email only supports (x)html and limited css. Unlike the ever-evolving web, popular email clients like Outlook for example, are out of date (and using the MS Word render engine). Much of html5/css3 that is common web practice today, is not widely supported across major email clients.
The only options you have as a link to more, is to host the additional information online (a landing page is typical), or to use anchor links and have the additional information further down in the email. Anchor links aren't 100% supported however. You may get iframes to work in one or two email clients but it will not work in most.
Javascript or any other server or client side language is NOT supported in email.
Part of my job involves turning psd designs into html to be emailed out for email campaigns. In the past I've always gone through and converted everything to a suitable html element where possible but I'm now questioning whether there's any point to it?
Is okay just to use one giant image? I only ask because it seems using html elements is only really important if a) I want the information in the email to get to the client if images are blocked and b) for SEO.. yet search engines won't be indexing my code since it's all going through email.
If I'm pretty confident that the clients I'll be mailing won't have the images blocked, is it okay just to treat the entire email body as an <img />?
Thanks
I guess it would be okay, but I wouldn't recommend it. Here are a few reasons why:
The readers won't be able to select and copy any of the content in the email, which in my opinion is really annoying.
You will not be able to have links in your email, the only thing you can link is the entire image.
If they do have images disabled, which i believe is fairly common, the wouldn't see a thing without downloading the image.
Increased email size due to the large image, which for mobile devices is a pain.
An image will not adapt to the window/display size. Text/HTML-based mails can at least break row if the content doesn't fit, to make it more readable.
And the list goes on. The other answers point out a number of additional reasons as well.
I don’t know that there is any definitive answer to this question, but here is my take on it:
I think it’s a good idea to convert certain elements to text so that they can be copied or manipulated. If you have a phone number, you may want that to be readable so that anyone with an automated dialer can click and complete the call. Certain email programs might automatically convert an address to a link to the map. Those features won’t work if any of these elements are flattened into the jpg.
For those mobile email clients that will not render the image on the screen (either because it’s just showing the preview or hasn’t yet downloaded the content) it’s useful to see some of the alternate text (and body content) before viewing the full image.
I know you said that you are sure your clients won’t have images blocked, but you can’t really rely on that. A well-meaning administrator who makes a change to the firewall could accidentally block all incoming images to the entire domain and your email will be worthless.
Lastly, an HTML email with one line of code to load an image has a high possibility of being flagged as spam.
I hope this helps!
What about bandwidth concerns, for users viewing your email on a mobile device? If it's a large image, do you want to blow out their data caps?
Or users using assistive technology, for visually-impaired people. Such as a screenreader(text to speech).The real text is helpful for scenarios like that.
It is theoretically possible to have a converter, that scans the color areas of a bitmap image and creates the same looking image, but using the CSS/HTML. CSS could be controlling colours of pixel-small html blocks. The further optimisation could be done by introducing the larger html blocks with similar color maps.
The resulting markup would be very large, but is it theoretically possible to achieve?
The main goal is to be able to e-mail clients a good looking promotional and informational e-mails, bypassing the problem of 99% of the recipients won't click to enable images in an e-mail. With such HTML-encoded images, a sender is sure that the e-mail looks as expected on the client side.
CSS does not reliably render in email. Bypassing any problems with your theoretical scanner, this is why images are the go-to standard in designed emails.
To see what I mean, look at Campaign Monitor's Guide to CSS support in email.
This would generate so much markup and put such a strain on the rendering engine of the recipient's email client that I don't think it would be viable in practice.
Also I wouldn't trust most email clients to render CSS accurately / reliably.
It is probably theoretically viable (in terms of actually generating the HTMl/CSS), although screen size may be an issue with this (for example divs could get pushed onto the next line whereas in the image they were inline).
Does the HTML/CSS for an html email newsletter need to be in table format, or can I use DIVs with equal assurance it will display well cross email-client? I've downloaded a number of templates to see how they're done, upon which to base my own, and they all seem to use tables.
Any insight much appreciated, thanks!
⚠️ Update 2021-06-10: This is a very old answer. I'm not sure how accurate it is 10 years after it was written. Mail clients are hopefully more compliant today ⚠️
When it comes to email HTML, note that all best practices from web development goes out the window. To make the look consistent, you should:
Use table based layouts
Use the old-school attribute styling for tables
Use ONLY inline-styles, and only very simple such. <style>-tags are discarded by many clients.
Skip using <html>, <head> and <body> - They will be discarded by most clients anyway.
If you embed images, try to make sure that the e-mail looks decent even if images are not loaded. Many clients require the user to mark the email as "safe" before displaying images.
You can read more detailed versions of the above points here:
http://articles.sitepoint.com/article/code-html-email-newsletters
http://dennisdeacon.wordpress.com/2008/06/09/top-10-email-best-practices/
http://www.catswhocode.com/blog/best-practices-for-coding-html-emails
Like everyone here has said, use tables and inline all your css... but there is an ecosystem of email apps to help you build emails.
I've been using Mailrox (https://www.mailrox.com/) for most of my email builds recently and it seem to be pretty damm good and outputting perfect HTML emails, if you're building one from a design, even though it's in beta.
You could also try pre-built templates from Mailchimp or Campaign Monitor, but it sounds like you have a design for your email so maybe Mailrox would be best.
If you really want to get into building emails I'd say forget most of what you know about modern webdesign and master table layouts and use the links from PatrikAkerstrand.
Litmus is also great for testing your hand-coded designs. They give you previews of your email in (pretty much) all the email clients.
Hope this helps.
Many email-clients aren't able to render css. I would use tables to format your mail and use images for anything else.
As it's already been mentioned - your HTML emails should be built using tables (and not divs). You can add CSS as well - both using an external stylesheet, but this will not be picked up by all email clients, so it's actually more reliable to add your css in-line. Even when doing so, some attributes might be ignored by certain email clients, so your best bet is still using HTML attributes whenever these are available. "You must do this because the some clients, such as Gmail, will ignore or strip out your tag contents, or ignore them." Source: http://webdesign.tutsplus.com/articles/creating-a-simple-responsive-html-email--webdesign-12978
That aside, I've also learned through trial and error that even images must be cropped to the exact size you want them displayed in your email. Outlook if terrible at picking up HTML attributes for width / height for images, and i have seen a few nasty stretched emails, only because these attributes were ignored and the images was displayed full size.
Do you attach the images?
Use absolute urls?
How do you best avoid getting flagged as spam?
One of the biggest causes, that I have found, for email to be flagged as spam is DNS. Make sure the domain / MX records from which you are sending the email actually resolve correctly back from the server used for sending.
As for images, you could attach them, but the most common way is to host them and use absolute urls. Primarily this is a bandwidth issue - you have to figure you're going to get an open rate of 10 - 15%: if you have to attach all the assets to every email, 85% of the bandwidth you'll use will be wasted.
You attach the emails then reference them in your HTML like so:
<img src="cid:imagefilename.jpg" />
Outlook, at least, recognizes this as a reference to an attached image and dumps it in appropriately.
You'll want to use absolute URLs to link out to images on a server. Users won't want to download your attachments. Also most email clients will not displays images by default, so it's a good idea to keep the really important content as text.
Email clients generally all use very different rendering methods. For example, Outlook 2007 uses Word's HTML rendering engine, whereas previous versions used Internet Explorer.
Do be aware that CSS support is also very limited to in emails. Most clients, especially web mail, will strip out everything outside of the <body> tag, as well as <style> tags. This means that external or embedded CSS will not work, and that inline styles are the safest bet (the style="" attribute). There is also poor support for many CSS rules in Outlook 2007. This means that a lot people have returned to using tables for laying out email.
As it was pointed out, Campaign Monitor is an excellent resource, and I especially recommend their CSS Compatibility Chart
Campaign Monitor is a great resources for html email:
http://www.campaignmonitor.com/resources/#building
Also http://www.email-standards.org/, but seems down right now.