[html] What is Data URI support like in major email client software?
I just tested GMail, and it appears that GMail no longer supports data URIs.
In addition, gmx.de (a very popular German web mail provider) converts image URIs to a URI on its server, and this doesn't seem to support data URIs.
Data URIs are a standard way to embed images and other binary data in HTML, and browser support is well documented on the web. (IE8 was the first version of IE to support Data URI, with a max 32 KB size per URI; other major browsers have supported it even longer.)
My question is about desktop email and webmail client software.
When building HTML email, standard practice is either to include images as attachments or load them externally (i.e. tracking images). Both of these have disadvantages (some clients list all of these attached files, while many rightly block or require user action to see external images). So, Data URI looks like a good way to go, but only if it's supported by email readers.
So, does anyone have a link to a recent study of support for this feature? Or investigated this at all? For example, here's an overview of CSS support. Client software I'd be interested includes:
Desktop (including version info): Outlook, Apple Mail, Thunderbird, Evolution, Lotus Notes, AOL, Eudora
Webmail: Gmail, Live/Hotmail, Yahoo! Mail, AOL
Mobile: Android, iPhone
I can't answer the question about the support for data-uri directly but support for anything like this is often very bad in email browsers. The issue really spans from many of them using their own cut down rendering engines that aren't full html renderers. In a system that it's still preferable to use a table based design to make sure emails are readable I wouldn't try to do anything clever.
However, you may already know that email allows two types of attachment. If you mark an attachment as inline then it tends not to show up in the list of attachments (though it often does).
I would think personally that ensuring the readability of the email is better than it not showing up and obviously the other approach of remote images doesn't help here.