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.
HTML E-Mails are a security nightmare, even if "only" CSS is "allowed" and JS/iframes/external images are not loaded.
You're basically advocating for text/richtext (aka text/enriched), which was originally proposed explicitly as a replacement for HTML in email. It failed essentially because everyone who didn't want HTML wanted only plain text, and everyone who wanted something like HTML was happy to just use HTML.
Factoid of the day: Netscape added support for a <blink> tag to text/enriched bodies, and that support remains in every client that's still using Netscape's MIME code. The comment above this code just says: "Of course, both text/richtext and text/enriched must be enhanced somehow... Or else what would people think."
> There are other text formatting standards which meet some of these criteria. In particular, HTML and SGML have come into widespread use on the Internet. However, there are two important reasons that this document further promotes the use of text/enriched in Internet mail over other such standards:
> 1. Most MIME-aware Internet mail applications are already able to either properly format text/enriched mail or, at the very least, are able to strip out the formatting commands and display the readable text. The same is not true for HTML or SGML.
> 2. The current RFC on HTML [RFC-1866] and Internet Drafts on SGML have many features which are not necessary for Internet mail, and are missing a few capabilities that text/enriched already has.
> For these reasons, this document is promoting the use of text/enriched until other Internet standards come into more widespread use. For those who will want to use HTML, Appendix B of this document contains a very simple C program that converts text/enriched to HTML 2.0 described in [RFC-1866].
It sounds to me like text/enriched was being proposed not so much as a replacement for HTML, but because HTML and related technologies were not yet mature enough. This wording expressly frames text/enriched as a stop-gap measure.
We use https://foundation.zurb.com/emails.html
It is essentially rows and columns, but the support has been great across Outlook and gmail, as well as mobile support.
I mean, different mime versions of the same content are a possibility to do this transition: Send both plaintext, HTML and markdown, and the receiver could choose to display markdown if he otherwise would display plain text.
To be honest, this won't come. Google is pushing AMP into mails, that's exactly the opposite direction.
Markdown strikes me as a much improved version of exactly this, with the advantage that you don't have to have a supporting client to read the email, since it's simply plain text.
I want to see email clients start to support Markdown, so I can just send it to everyone.
Markdown is nice for composing, but not as a standard to be supported by many clients. CommonMark is an improvement, but there is way to many ambiguities and differences in supported features over different markdown parsers for it to be feasibly used as a standard.
Markdown is also not any better than HTML in terms of security - most markdown parsers allow passing through arbitrary HTML, and then depend on sanitizing the HTML for security.
What you are asking for is effectively a smaller subset of HTML to be used for for email (which is kind of how it started...)
This is a bigger issue than most people care to admit. I post stuff to a number of different sites that support "Markdown" and not a single one agrees on even something a simple as how to format a hyperlink. I end up having to hit the help page on every site to remember which syntax they use, if they even support the feature at all. HTML might be "ugly", but at least it is consistent.
Not sure why you're being down-voted. (As usual here, only clicking a down-vote button contributes little value.)
- You are correct that implementing markdown consistently is hard because there is no real spec. CommonMark is a spec, which helps, but a heroically thorough spec, so it's still not exactly trivial to implement.
- You are correct that markdown can escape to HTML. Indeed certain marketing email "features" probably would do this?
If I am missing something maybe someone could make an actual contribution to the discussion and explain.
In any case I think by far the most important point was made elsewhere: Google AMP is awful for the web and for email, both.
p.s. edit: Actually, I think the even more important point is that anything except plain text email is awful. :) So there, sure, use markdown or org-mode formatting conventions. Humans are pretty good at handling messy human protocols.
Markdown Here appears to be unmaintained and is certainly incompatible with Thunderbird 68.0. I have not been able to raise the developer of it at all and PRs are not being merged.
The idea behind Markdown Here is good, but it has some issues like keeping a copy of the markup text base-encoded in some html attribute which can be lead to unintentionally leaking full text while forwarding part of the message.
The idea of markdown is great because it it essentially a text. Even if the client would not support it, humans would be able to read it just fine. Much better and more secure than rich HTML. For example my email client won't display images by default and I am happy with that. Rich HTML should be on the web only IMO!
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")
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 use Gnus in Emacs as my email client. I've got it set up to render plain text if available, but if the mail is only HTML, it will fallback to use Emacs' shr (Simple HTML Render) library. It's basic support, but works well enough most of the time to make the mail readable. Worse comes to the worse, I just open the HTML in a web browser. If I get to that stage, it's almost always spam or something else not worth reading.
Doesn't (al)pine support html part out of the box (not sure, been a while since I used pine). I'd imagine support for more mime types that eg Gmail via:
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!
I think that https://www.caniemail.com in many cases would be a timewaster. Because you spend your time exploring each individual CSS/HTML feature availability and later on realizing something can not be done in fully crossbrowser/cross-email-client way.
Instead you could just accept the limitation of MJML and start coding the final version right away.
CSS in email clients is a mess. Like IE6 on steroids.
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.
Mailchimp has a pretty good guides on how to create cross-compatible layouts:
From what I remember outlook uses the word rendering engine. Writing any kind of layout that works on all email clients is absolute hell. For most complex layouts it seems most companies just send it as an image with the text being the only other element
Looks like they at least followed the IE pattern of having conditional comments. Embedding IE CSS hacks in one place (and possibly degrading the site) made working with IE almost tolerable.
I wonder what content-types email clients support besides HTML and plaintext. Would any support mp3, mp4, markdown, org or odt?
EDIT: Hmmm found this[1], and this[2]. They talk about using TROFF, TEX, Postscript, voice data, etc. I wonder if something like that ended up implemented somewhere.
Very few enterprises these days provide a “Text only, please” option in
their E-Mail subscription options. Jira is, by all means, terrible
software, but at least they do have this feature. I guess it's one of
those situations where few people understand what it is and why you
would want that. And even less people who care.
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).
You don't get it. Stuff like this does not discourage designers. It is what gets them jobs and keeps them employed. I've worked with marketing departments where it was a designer's primary job to make things look good on email campaigns.
Microsoft's history has shown time after time that both internal conflict and external enterprise clients' requests lead to random developers adding bits and pieces of non-standard features. This applies not only to Outlook but their other products (incl. Windows). It is goddam' Wild West out there and they clearly give no crap about how the standards outside of their universe evolve.
Sorry Microsoft, but the PC world is not Windows-only anymore.
Nope, believe it or not, ever since Outlook 2007 it uses the HTML rendering engine from Word itself. Seriously! Someone at Microsoft looked at Outlook and said "this needs to have the same rendering capabilities as noted Web browser Microsoft Word." Sheesh.
Office for Windows still uses Internet Explorer as the renderer for addins built with OfficeJS, unless you're on Windows 1903 and using an insider version of Office.
I had depressed thoughts when I discovered I would be having to debug Internet Explorer in 2019.
I'd love to hear from some insiders how all these non standard outputs get decided inside MS. I can imagine a lot of scenarios based on experience and just thinking it out but I'd love to hear the real story.
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.
Readit News
HTML E-Mails are a security nightmare, even if "only" CSS is "allowed" and JS/iframes/external images are not loaded.
Factoid of the day: Netscape added support for a <blink> tag to text/enriched bodies, and that support remains in every client that's still using Netscape's MIME code. The comment above this code just says: "Of course, both text/richtext and text/enriched must be enhanced somehow... Or else what would people think."
> There are other text formatting standards which meet some of these criteria. In particular, HTML and SGML have come into widespread use on the Internet. However, there are two important reasons that this document further promotes the use of text/enriched in Internet mail over other such standards:
> 1. Most MIME-aware Internet mail applications are already able to either properly format text/enriched mail or, at the very least, are able to strip out the formatting commands and display the readable text. The same is not true for HTML or SGML.
> 2. The current RFC on HTML [RFC-1866] and Internet Drafts on SGML have many features which are not necessary for Internet mail, and are missing a few capabilities that text/enriched already has.
> For these reasons, this document is promoting the use of text/enriched until other Internet standards come into more widespread use. For those who will want to use HTML, Appendix B of this document contains a very simple C program that converts text/enriched to HTML 2.0 described in [RFC-1866].
It sounds to me like text/enriched was being proposed not so much as a replacement for HTML, but because HTML and related technologies were not yet mature enough. This wording expressly frames text/enriched as a stop-gap measure.
https://github.com/mozilla/releases-comm-central/blob/master...
Try out the online examples.
Having email rendered consistently across many email clients was the main reason we stayed with Mail Chimp for so long...
I mean, different mime versions of the same content are a possibility to do this transition: Send both plaintext, HTML and markdown, and the receiver could choose to display markdown if he otherwise would display plain text.
To be honest, this won't come. Google is pushing AMP into mails, that's exactly the opposite direction.
I want to see email clients start to support Markdown, so I can just send it to everyone.
Markdown is also not any better than HTML in terms of security - most markdown parsers allow passing through arbitrary HTML, and then depend on sanitizing the HTML for security.
What you are asking for is effectively a smaller subset of HTML to be used for for email (which is kind of how it started...)
- You are correct that implementing markdown consistently is hard because there is no real spec. CommonMark is a spec, which helps, but a heroically thorough spec, so it's still not exactly trivial to implement.
- You are correct that markdown can escape to HTML. Indeed certain marketing email "features" probably would do this?
If I am missing something maybe someone could make an actual contribution to the discussion and explain.
In any case I think by far the most important point was made elsewhere: Google AMP is awful for the web and for email, both.
p.s. edit: Actually, I think the even more important point is that anything except plain text email is awful. :) So there, sure, use markdown or org-mode formatting conventions. Humans are pretty good at handling messy human protocols.
I've used it on several projects, it speeds things up quite a bit
https://github.com/adam-p/markdown-here/issues/577
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.
http://alpine.x10host.com/alpine/alpine-info/misc/mime.html
But I might be wrong. I thought both pine and mutt would handle html through w3m or something?
I think that https://www.caniemail.com in many cases would be a timewaster. Because you spend your time exploring each individual CSS/HTML feature availability and later on realizing something can not be done in fully crossbrowser/cross-email-client way. Instead you could just accept the limitation of MJML and start coding the final version right away.
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.
Mailchimp has a pretty good guides on how to create cross-compatible layouts:
https://templates.mailchimp.com
And this tool to test emails before sending: https://litmus.com/
> No results found. Why not suggest this feature to be added?
It's worth sending a pull-request.
EDIT: Hmmm found this[1], and this[2]. They talk about using TROFF, TEX, Postscript, voice data, etc. I wonder if something like that ended up implemented somewhere.
EDIT 2: I opened an issue[3].
[1] https://tools.ietf.org/html/rfc1049
[2] https://tools.ietf.org/html/rfc767
[3] https://github.com/hteumeuleu/caniemail/issues/23
Very few enterprises these days provide a “Text only, please” option in their E-Mail subscription options. Jira is, by all means, terrible software, but at least they do have this feature. I guess it's one of those situations where few people understand what it is and why you would want that. And even less people who care.
The Outlook ecosystem has to die.
Sorry Microsoft, but the PC world is not Windows-only anymore.
Dead Comment
For those who don’t know, it’s was Microsoft WYSIWYG website builder that looked similar to Word, from 20 years ago.
https://en.m.wikipedia.org/wiki/Microsoft_FrontPage
I had depressed thoughts when I discovered I would be having to debug Internet Explorer in 2019.