It would be really nice to have a small and simple markup language, say some markdown standard, to be the layouting language for E-Mails. No (external) images, just links, lists, headings, basic formatting.<p>HTML E-Mails are a security nightmare, even if "only" CSS is "allowed" and JS/iframes/external images are not loaded.
It might be interesting to include "pine" and "mutt" as well, as a baseline of mail clients that do not support HTML out of the box. (At least with mutt you can set it up to automatically render HTML emails via "w3m")<p>More importantly, though, I convinced all mail clients I use to just show plain text when viewing and writing my emails. Often there are HTML emails in which I do not see all the content, or content at all. For me this is nice because most HTML emails I get are spam, marketing related, or organizational nonsense.
I'm surprised to find no mention of MJML on this thread - it's more of a developer tool than a user facing one. You get to design your emails using a simplified markup language that resembles HTML, and it converts it into minified HTML that works pretty well on most email clients. Kudos to the guys behind it!
CSS in email clients is a mess. Like IE6 on steroids.<p>I switched to a Windows on my work laptop about 6 months ago, and the native Win 10 email client is probably the worst offender out there. Even the popular mailing lists (like IH, PH, etc) are completely broken to the point of unreadable in Windows 10 Mail.<p>Mailchimp has a pretty good guides on how to create cross-compatible layouts:<p><a href="https://templates.mailchimp.com" rel="nofollow">https://templates.mailchimp.com</a>
I've used this guide to navigate email styling nightmare: <a href="https://www.campaignmonitor.com/css/" rel="nofollow">https://www.campaignmonitor.com/css/</a><p>And this tool to test emails before sending: <a href="https://litmus.com/" rel="nofollow">https://litmus.com/</a>
> <i>Can I email </i>plaintext<i></i>?<p>> <i>No results found. Why not suggest this feature to be added?</i><p>It's worth sending a pull-request.
Christ on a bike, the state of Outlook on Windows is absolutely miserable. I knew it by experience when I started preparing HTML signatures for our company, but seeing the list makes me even sadder about the absolute state of incompetency caused by legacy systems in Microsoft. For those uninformed, Outlook on Windows effectively works on a terrible (and terribly old) implementation of HTML that was initially developed for Word from 2001 (or older, can't remember exactly).<p>The Outlook ecosystem <i>has to</i> die.
Nooooo! More plain text and less html. If we need to, lets define a strict subset, lets call it html5-lite and it will only have a handful of tags and two css modes that are not user definable.
I'm just now trying to send some mathematics in an email (where most recipients will be reading it in Gmail), so I'm having to figure out what subset of HTML and CSS Gmail supports. (Found this reference for CSS: <a href="https://developers.google.com/gmail/design/reference/supported_css" rel="nofollow">https://developers.google.com/gmail/design/reference/support...</a>) It turns out that simply using MathJax or KaTeX and pasting the resulting web page into an email doesn't work: Gmail doesn't support SVG images (security concerns?), so one needs to convert images to PNG, but then converting every $n$ or $x$ into a separate image feels like overkill (the email would become huge and slow to load), so it would be nice to only convert expressions that “really” need it. It seems Pandoc by default has a mode where it converts only “simple” expressions and throws a warning on math that cannot be converted to simple HTML (using "em" and "sup" tags and a Unicode alphabet for things like ∑), so we can use this as a trick to identify which math expressions need conversion to images. Then if any of these images occurs inline, we need to figure out the baseline problem.<p>And so on... Funny how trying to do the slightest thing with technology (send some mathematics over email) immediately turns into a research project.
This is really helpful - kudos!<p>Sidenote: you can always avoid the hassle of testing HTML/CSS across email clients by just using plain text. :P<p><a href="https://bradleytaunt.com/plain-text-emails/" rel="nofollow">https://bradleytaunt.com/plain-text-emails/</a>
Anyone wanna chime in on conversion rates when it comes to styled vs. plain text? I always hear that the latter converts better, i.e. "Make it look like as if it was sent by a friend" and obviously it's a business related matter but I wonder why plain isn't used more often when visuals/emotion aren't the #1 selling points.
You send me anything other than plain text in an email, and I don't already have a source filter for your address, it gets sent to a folder that I might look at if I have the time some day.
I'm all over for using cutting edge CSS solutions but when it comes to HTML email, I'm just:<p><pre><code> <h1>Hello</h1>
<p>...</p>
<p>...</p>
<em>Thanks!</em>
</code></pre>
and it's done :)
Why using plain text is better:<p>- readable under any mail client and any text editor<p>- smaller size files<p>- safer<p>- better accessibility and compatibility with screen readers
Just saw Rémi Parmentiers talk at SmashingConf 2019, worth a watch, it's not online yet though, so you guys might have to wait a day or two. He's the guy behind this project and probably one of the most knowledgable persons about everything email.
> This page ranks email clients based on their support among the 58 HTML and CSS features listed on Can I email.<p>> (Because every test is done manually, some features might not have been tested on every email client.)<p>I wonder, could they not create a single test email exercising all 58 features? Then one would just have to open the test email in a given client and compare it to a reference rendering. (Kind of like the Acid1/2/3 tests of yore.)
My goodness, this HTML in email things could cost you a job. I was burnout once by making 30 emails with variable layout work across popular email clients and screen sizes. Can I Email is definitely needed. But I will never do these fancy marketing emails ever again. Use plain text to communicate for your whatever incoming campaigns. Or if we really want HTML just use it without stylesheet, just plain tags.
I just use premailer[1] to automatically convert the email html I write to outlook compatible html 0.1 gibberish<p>[1]: <a href="https://github.com/peterbe/premailer" rel="nofollow">https://github.com/peterbe/premailer</a>
Have been using Cerberus since 2016 for responsive emails with no issues:<p><a href="https://github.com/TedGoas/Cerberus" rel="nofollow">https://github.com/TedGoas/Cerberus</a>
I'm not sure if I want email clients to support more html&css. I kind of like them to be lighter and with less features.<p>Actually, I'd prefer if they added something like CommonMark and removed HTML.
No, you should not use any of these. You should only use plain text.<p><a href="https://useplaintext.email" rel="nofollow">https://useplaintext.email</a>
I've spent a year of my life working on a front-end for visual composer tool for emails, and it was a horrible experience, time-travel back to IE6 era. I wish there was some tool like this back then, I'd probably keep it open in a tab all the time. We desperately need for someone to finally win this mail client war and some standardization to emerge.
This resource would be more useful if it also indicated support for relevant email-only features:<p>* Blocking of remote resource loads<p>* Which resources can be loaded via multipart/related and cid: links.<p>* How are doctype-less HTML bodies loaded<p>* "Leaking" of HTML parts in a multipart/mixed message
This is good! I have searched for this actually.<p>However this seems to lack the most important thing (for me): the global usage percentage of a particular feature, which is the #1 deciding factor whether to use a HTML/CSS feature or not.
This is very cool. One feature I'd like is the market share report that caniuse has for each listing.<p>I currently rely on <a href="https://emailclientmarketshare.com/" rel="nofollow">https://emailclientmarketshare.com/</a> (by Litmus) for this but if someone's aware of a better data source, I'd like to know.
I got to use BBN Diamond <a href="https://tools.ietf.org/html/rfc910" rel="nofollow">https://tools.ietf.org/html/rfc910</a> and it worked well. It was quite surprising to me when it turned out SGML failed and HTML succeeded.
Will be very helpful in building an SGML DTD grammar for the HTML subset usable in emails, like I did with regular HTML [1]. CSS, though ... will have to wait for a little longer.<p>[1]: <a href="http://sgmljs.net" rel="nofollow">http://sgmljs.net</a>
For me discovering <a href="https://mjml.io/" rel="nofollow">https://mjml.io/</a> was the best thing as it takes away the pain of having to think about all the nitpicks of the different email clients and abstracts it into it's own little markup language.<p>It supports responsive email designs and has many examples which you can alter to your needs.<p>You can see the power here: <a href="https://mjml.io/try-it-live" rel="nofollow">https://mjml.io/try-it-live</a> the basic 15 line example expands to 188 lines of html so that it looks the same everywhere.