Can I Email: ‘Can I Use’ for email(caniemail.com)
caniemail.com
Can I Email: ‘Can I Use’ for email
https://www.caniemail.com/
205 comments
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."
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."
From RFC 1896:
> 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.
> 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.
Looks like the comment remains there. :)
https://github.com/mozilla/releases-comm-central/blob/master...
https://github.com/mozilla/releases-comm-central/blob/master...
No markdown, but we had success with this one: https://mjml.io/
Try out the online examples.
Try out the online examples.
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.
The only problem I guess is that the last release was over three years ago, and some bugs are starting to show (saying nothing of any added features). The pace of the npm environment is moving so fast, that it's sometimes hard to even get a project up and running.
Things feel a little stale.
For example (from this week of my adventures with Foundation for Emails) Google Fonts almost sort of work for email, but there's just no real easy way to tell this framework to use them, or call any web font.
Things feel a little stale.
For example (from this week of my adventures with Foundation for Emails) Google Fonts almost sort of work for email, but there's just no real easy way to tell this framework to use them, or call any web font.
Wow, that's pretty cool, what's the consistency across different clients like?
Having email rendered consistently across many email clients was the main reason we stayed with Mail Chimp for so long...
Having email rendered consistently across many email clients was the main reason we stayed with Mail Chimp for so long...
It's pretty good. A few clients are still PITA (looking at you, Outlook 2007 and Yahoo mail. You still have to do jump through hoops for accurate background images, or fancy things with borders.
The actual markup MJML generates is terrifying, and can be very large payloads. A simple hero graphic, some styled body text, a few buttons, and a footer was around 60KB/message. It got gnarly for us as our MTA had a max-payload size per API 'send' call (Mandrill) so our max send rates were partially constrained by MJML's fat markup.
But totally worth it to not spend _as_ much time satisfying the mail clients of the world.
The actual markup MJML generates is terrifying, and can be very large payloads. A simple hero graphic, some styled body text, a few buttons, and a footer was around 60KB/message. It got gnarly for us as our MTA had a max-payload size per API 'send' call (Mandrill) so our max send rates were partially constrained by MJML's fat markup.
But totally worth it to not spend _as_ much time satisfying the mail clients of the world.
I agree with all of this. When you really start to dig in to cross-client compatibility (and you observe what MJML does to provide it) you start to get a sense that NOT using a tool like MJML is a hopeless path.
Thanks, looks like a great solution.
Something like this? http://www.rfc-editor.org/rfc/rfc1896.txt
Email is so fun, every time someone comes with a new idea, someone pulls out an RFC detailing it. Dated 20+ years back.
It even has a predecessor from 1992, see paragraph 7.1.3 of http://www.rfc-editor.org/rfc/rfc1341.txt .
Thanks for the RFC link. Yes, basically.
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 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.
It’s so stupid. If AMP emai ever became a thing, every single non google email client would just fetch and store the contents of the AMP page the moment an AMP email arrives. So what was the point of it?
Not so sure about that, not downloading anything extra and only showing what is embedded in the email is one of the good things with using an email client. Using AMP email is back to thinking tracking pixels works in emails
If the content isn't inline, perhaps it's better to have the mail server fetch it when the email is received, so that the sender can't track whether you are reading it.
This has been discussed before with regard to external links to images. I think that always made sense, but it makes even more sense to do this when the core content is external. Then fetching it would be just another part of the SMTP/HTTP transaction sequence to deliver a mail.
This has been discussed before with regard to external links to images. I think that always made sense, but it makes even more sense to do this when the core content is external. Then fetching it would be just another part of the SMTP/HTTP transaction sequence to deliver a mail.
Exactly. If most mail clients downloaded it automatically upon receipt instead of on view then the tracking benefits get diluted to the point of uselessness.
(Actually, thinking further it would have to be done server side to avoid leaking your personal IP. For a webmail provider that’s obviously straightforward, while IMAP servers could be extended to automatically replace AMP email directives with a static HTML attachment.)
(Actually, thinking further it would have to be done server side to avoid leaking your personal IP. For a webmail provider that’s obviously straightforward, while IMAP servers could be extended to automatically replace AMP email directives with a static HTML attachment.)
Should it do that for all emails sent to the domain, or only for valid addresses? If they only fetch for addresses in use this will open up for an easy way for spammers to verify if an address is in use or not
Spammers can already verify if an address is _accepted_ because their message will be rejected with an error code at SMTP transmission time if it isn't.
The first stage of spam filtering, and greylisting, also reject at SMTP transmission time.
I'd do the HTTP fetch when SMTP is about to accept the message, making the HTTP round trip just another part of the transaction.
Since spam filtering is likely to look at the HTTP response, you might want to reject the SMTP transaction after seeing the HTTP response, rather than accept the SMTP transaction based on address alone.
The first stage of spam filtering, and greylisting, also reject at SMTP transmission time.
I'd do the HTTP fetch when SMTP is about to accept the message, making the HTTP round trip just another part of the transaction.
Since spam filtering is likely to look at the HTTP response, you might want to reject the SMTP transaction after seeing the HTTP response, rather than accept the SMTP transaction based on address alone.
Isn't AMP for email kinda what you are describing?
"The AMP version of the message is embedded into the email as a new MIME part, in addition to the HTML and plaintext, ensuring compatibility across all mail clients"
From https://amp.dev/documentation/guides-and-tutorials/start/cre...
"The AMP version of the message is embedded into the email as a new MIME part, in addition to the HTML and plaintext, ensuring compatibility across all mail clients"
From https://amp.dev/documentation/guides-and-tutorials/start/cre...
Isn't markdown just turned into html?
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.
I want to see email clients start to support Markdown, so I can just send it to everyone.
Not just email, I’d like to see browsers support Markdown natively. You can style your content. All media sites can be 100% markdown without any JS.
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...)
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.
I wish there was a browser extension to handle that. It would provide an editing area that would allow you to edit using the same markup on different sites, and when you are done would translate to whatever markup format that site uses and fill in the site's edit area with that.
There are some bits of typical markdown syntax that I really don't like. Like pasting code requires you to add 4 spaces to the start of every line and an extra linefeed between each line. That's a lot of work and every time I do it I say "How is this better than <pre></pre>?"
I've yet to see what I'd really like: preformatted text being surrounded by markers that make it easy to paste in, like so:
I've yet to see what I'd really like: preformatted text being surrounded by markers that make it easy to paste in, like so:
Some regular text
vvvvv
Preformatted text
^^^^^
The most common way to do this is with triple backticks:
Some regular text
```
Preformatted text
```
This syntax even made its way into CommonMark (https://spec.commonmark.org/0.29/#fenced-code-blocks)
> ...every time I do it I say "How is this better than <pre></pre>?"...
From Gruber’s Markdown spec:
> Readability, however, is emphasized above all else.
From Gruber’s Markdown spec:
> Readability, however, is emphasized above all else.
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.
- 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.
Why is markdown so popular? It seems so braindead.
# why is markdown so popular?
## (my opinion)
Markdown is fast to type for the majority of use cases since you have:
- bullet points
- headings
- __bold__
- __italic__
- `inline code`
- etc
```
fn you_even(_have: &str) -> &str { "nifty little code blocks without needing to indent" }
```
And more importantly, markdown syntax preserves the structure of the document without harming legibility, unlike say latex or HTML. That limits it, since the syntax is small, but also reduces friction in learning/writing markdown.
Also, Reddit + GitHub.
Markdown is fast to type for the majority of use cases since you have:
- bullet points
- headings
- __bold__
- __italic__
- `inline code`
- etc
```
fn you_even(_have: &str) -> &str { "nifty little code blocks without needing to indent" }
```
And more importantly, markdown syntax preserves the structure of the document without harming legibility, unlike say latex or HTML. That limits it, since the syntax is small, but also reduces friction in learning/writing markdown.
Also, Reddit + GitHub.
Sorry, poor choice of words.
I thought hacker news used markdown, but I guess has its own thing.
I can see the severely constrained formatting options of hacker news has both positive and negative consequences.
I thought hacker news used markdown, but I guess has its own thing.
I can see the severely constrained formatting options of hacker news has both positive and negative consequences.
[deleted]
Try Foundation https://foundation.zurb.com/emails.html
I've used it on several projects, it speeds things up quite a bit
I've used it on several projects, it speeds things up quite a bit
Beside, I am using Markdown in all my email thanks to https://markdown-here.com/ and Thunderbird
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.
https://github.com/adam-p/markdown-here/issues/577
https://github.com/adam-p/markdown-here/issues/577
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!
This + multipart/alternative email and maybe something like uMatrix or similar firewall mechanisms in mail clients
But isn't Markdown a sugar on top of HTML? When something does not fit Markdown one is supposed to write inline HTML.
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.
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:
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?
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?
Pine (or rather Alpine) does have HTML support built in and enabled by default.
Same for me. I have a 'newsletters' folder which is the only one for which mutt will try to show me the HTML part first. Otherwise, it's plain text.
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!
MJML is great.
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 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.
This is the correct response and really needs to be upvoted for everyone to see.
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:
https://templates.mailchimp.com
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
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
As someone who builds email regularly for Outlook - table based layouts work best, if you want to be fancy one could do some fancy VML stuff.
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've used this guide to navigate email styling nightmare: https://www.campaignmonitor.com/css/
And this tool to test emails before sending: https://litmus.com/
And this tool to test emails before sending: https://litmus.com/
Campaign Monitor's documentation has been the go-to solution for years. But I'm sure everybody working with email HTML already knows about it.
> Can I email plaintext?
> No results found. Why not suggest this feature to be added?
It's worth sending a pull-request.
> No results found. Why not suggest this feature to be added?
It's worth sending a pull-request.
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.
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
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
E-Mails typeset in TeX sounds amazing! Right now you'd have to compile
your TeX code to PDF/PS/DjVu and send that, which is far from perfect.
And imagine opening an E-mail that contains a PhD paper requires 15 minutes of compilation...
Plaintext? Is that a new CSS framework? /jk
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.
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).
The Outlook ecosystem has to die.
The Outlook ecosystem has to die.
Everything that discourages designers from doing fancy things is good in my book.
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.
I had a recent request from a product owner to style the subject line... I said we can't do that and that I don't want to live in a world where senders can change the font or size of the subject in an email.... Can you imagine the crap we would have from spam in that case?!
You can always pack it with emojis and unicode characters... that's what all the spammers seem to do at least.
Y̗̳̬͍̘͚o͘u͏ ͏̬̟̩h̦̕a̰̖͍̟v̧̯̜͉͙̖͖͉e҉̳̲̙͚̗̬ ̤͚͉̀w̢̫͎̮̼͇o̷̮̙̩n̪͙͎̠͔ ̻̮a̛̭ ̡̪̤̻ͅp̵̭͇r̩͉į̬̺̭̯͍͙z̯͈͟e!͖̖͈̯
ie don't any mua let you use UTF8?
𝔻𝕠𝕖𝕤 𝕥𝕙𝕚𝕤 𝕨𝕠𝕣𝕜?
ie don't any mua let you use UTF8?
𝔻𝕠𝕖𝕤 𝕥𝕙𝕚𝕤 𝕨𝕠𝕣𝕜?
The first one does not work great in a terminal. The words are readable but I don't get the full experience.
The second one, pretty good.
Seems like your terminal doesn't support the last line. I will repeat all three lines in tunarly fashion.
Line 1:
" You have wøn a prize! "
Unincluded line; my sister got bitten by a prize once. Or a terminal. Onto line twø: two:
Line two: (2:)
" ie don't any mua let you use UTF8? "
And three:
" Does this work? "
All the lines for all the good people. The " signs " are a delimiter for each line. They're, or should be pretty verbatim, minus the unrenderability.
Have fun.
Line 1:
" You have wøn a prize! "
Unincluded line; my sister got bitten by a prize once. Or a terminal. Onto line twø: two:
Line two: (2:)
" ie don't any mua let you use UTF8? "
And three:
" Does this work? "
All the lines for all the good people. The " signs " are a delimiter for each line. They're, or should be pretty verbatim, minus the unrenderability.
Have fun.
Ah, I referred to the third line, "𝔻𝕠𝕖𝕤 𝕥𝕙𝕚𝕤 𝕨𝕠𝕣𝕜? ", as the "second one" in my message, without mention for line 2, which renders correctly, fortunately. But thanks for the heads up.
Firefox on mobile mangle that pretty bad on - at least the vertical space :/
Firefox Mobile renders it well for me, are you sure that the comment is not rendered as it should be (with garbage from line 1 overflowing over line 2)?
I thought the owerflow should be "well behaved" (in terms of correct layout/vertical space)?
Is it correct to have "overhang" into the line below? Isn't it a case of incorrect layout?
Is it correct to have "overhang" into the line below? Isn't it a case of incorrect layout?
I think it is correct, as surprising as it can be.
See this famous stack overflow answer for instance: https://stackoverflow.com/a/1732454
Indeed, if it's possible, marketing is going to ask for it. And unless you have dedicated developers who specialize in email campaigns, ready to brave the nightmare that is fighting against email client formatting, the only sane and cost-effective solution to implement any kind of layout in an email is simply stacking inline images with text included.
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.
Sorry Microsoft, but the PC world is not Windows-only anymore.
By the same logic you could say that internet explorer was doing good things
No, the logic is: I want styled content on the Web and plain text in my emails.
It's not a new problem and MIME was intended to give people the choice. Not everyone likes plain text emails or terminal email clients. The solution may be forcing email senders to include text/plain as well as text/html.
For that very reason you have MIME type setting
I believe Outlook still uses the Microsoft Frontpage html engine.
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
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
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.
I think they thought ‘lets just use Word to compose replies, but to prevent the email from getting corrupted once the user hits reply, we’ll already mangle it on the way in so the sender gets the blame’
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 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.
The samsung email client manages to support flexbox, along with pretty much every other client but AOL... and Outlook Windows.
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: https://developers.google.com/gmail/design/reference/support...) 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.
And so on... Funny how trying to do the slightest thing with technology (send some mathematics over email) immediately turns into a research project.
And so on... Funny how trying to do the slightest thing with technology (send some mathematics over email) immediately turns into a research project.
That's why most folks I know either write a short latex file (and append pdf+tex) or write pseudo code or full latex code because... The recipient understands latex.
But honestly, this is way more portable then mathjax or MathML or whatever. Consider using a latex enabled chat when it really differs.
But honestly, this is way more portable then mathjax or MathML or whatever. Consider using a latex enabled chat when it really differs.
Yes, those were two other options I considered. Ultimately both require higher effort from the reader (view the PDF, or mentally parse LaTeX syntax or have something special installed that does so), neither of which is conducive to quick skimming etc. Just optimizing for reader convenience. :-)
Have you done any benchmarking on the sizes of the images? I cannot imagine a JPEG math expression, cached by google, is going to take an age to load when viewed in Gmail and not be that large.
That's a good question. The actual size of the images is not large: the problem is that I can visually see the email take a while to load properly, even for an email containing just two PNG images that are 2941 bytes and 6333 bytes respectively. If nearly every sentence were to be interrupted a few times with such delayed-loading images, the reading experience would be rather poor.
(This was with the images self-contained in the email, which seems to be implemented under the hood by having them be attachments and referring to them in the body, so the loading happens out of order... I haven't tried with the images being loaded as external images, but that has its own problems such as Gmail probably not loading them by default, or having to ensure the images will be available over the internet for as long as anyone might want to read the email which if you're sending it to a mailing list is ideally forever, etc.)
(This was with the images self-contained in the email, which seems to be implemented under the hood by having them be attachments and referring to them in the body, so the loading happens out of order... I haven't tried with the images being loaded as external images, but that has its own problems such as Gmail probably not loading them by default, or having to ensure the images will be available over the internet for as long as anyone might want to read the email which if you're sending it to a mailing list is ideally forever, etc.)
Try embedding Base64 images in the email instead:
<img src="data:image/png;base64,iVBORw0K...=">Inline base64 shouldn't have any head of line blocking or slow rendering issues, unlike embedded images-as-mime-attachments, which will normally result in one HTTP request to gmails servers per image, and without QUIC you'll get head of line blocking and limited/no HTTP pipelining making that very slow.
Inline base64 should perform fine for small images up to ~10k images I'd guess on most hardware.
If your email contains more than 10k math equations, perhaps email isn't the right tool...
Inline base64 should perform fine for small images up to ~10k images I'd guess on most hardware.
If your email contains more than 10k math equations, perhaps email isn't the right tool...
That's what the LaTeX It! Thunderbird add-on [1] does I think. Good extension by the way. Not sure it will work with Thunderbird 68, I didn't check.
[1] https://addons.thunderbird.net/en-US/thunderbird/addon/latex...
[1] https://addons.thunderbird.net/en-US/thunderbird/addon/latex...
This is really helpful - kudos!
Sidenote: you can always avoid the hassle of testing HTML/CSS across email clients by just using plain text. :P
https://bradleytaunt.com/plain-text-emails/
Sidenote: you can always avoid the hassle of testing HTML/CSS across email clients by just using plain text. :P
https://bradleytaunt.com/plain-text-emails/
[deleted]
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.
Thinking in terms of "conversion rates" feels to me like the reason why we're in this mess. Email to me isn't about conversion and advertising newsletters. It's about written information, so there's no reason to even support HTML, in most cases.
Arguably there's situation where an image will help in conveying information, or where a table will make information more readable. There's no situation where CSS is required.
Arguably there's situation where an image will help in conveying information, or where a table will make information more readable. There's no situation where CSS is required.
Written information clearly benefits from bold, italics, ordered and unordered lists, section headers, etc. Normal people don’t really understand text surrounded by underscores or asterisks (I never receive messages with those constructs from non-technical people).
Formatting lists or indented quotes (also common in “normal” email usage) using white spaces and other semi-arbitrary characters is tedious and brittle.
The “rich text” features of HTML email definitely improve readability and understanding when used with restraint.
Formatting lists or indented quotes (also common in “normal” email usage) using white spaces and other semi-arbitrary characters is tedious and brittle.
The “rich text” features of HTML email definitely improve readability and understanding when used with restraint.
It is useful to have a way to represent structural and semantic information in email text (paragraphs, headings, quotes etc.), but not custom layouts and styling — that should remain under full control of the reader.
Include an URL to any external content. All URLs are plaintext, ideally.
My 3845743985793847948 gigabyte Linux ISO. Is here, in email-contextual plain text: http:/linux.iso/3845743985793847948/gib
My xes tapes? All stored at this address http://xes.sepat/all
What's the problem. Email works. Without formatting.
My 3845743985793847948 gigabyte Linux ISO. Is here, in email-contextual plain text: http:/linux.iso/3845743985793847948/gib
My xes tapes? All stored at this address http://xes.sepat/all
What's the problem. Email works. Without formatting.
I think images are used for marketing emails because spam filters are worse at detecting them.
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.
So you don't buy things online or travel or do your taxes digitally?
99% of important transactional email I get is HTML. Kind of nice to have your boarding passes and two-factor authentication emails easily visible.
99% of important transactional email I get is HTML. Kind of nice to have your boarding passes and two-factor authentication emails easily visible.
Most such mail tends to be not just HTML but rather multipart/alternative with an HTML but also a text/plain part.
Luckily, HTML only (or its bastard cousin: including a text/plain part that is horribly broken or just says "please enable HTML viewing") isn't seen that often around here.
Luckily, HTML only (or its bastard cousin: including a text/plain part that is horribly broken or just says "please enable HTML viewing") isn't seen that often around here.
Normally one does business on the website and then what one gets in their mail isn't an interactive utility running in their mail client but rather either some record of the transaction you will rarely need or a link to complete some activity on their actual website.
Click this link to reset your password or some such.
Click this link to reset your password or some such.
How do you filter for plain text (look)? Given that most clients will send html version along with the plain text?
I'm all over for using cutting edge CSS solutions but when it comes to HTML email, I'm just:
<h1>Hello</h1>
<p>...</p>
<p>...</p>
<em>Thanks!</em>
How about this?
Hello
...
...
Thanks!I want to have embedded links, tables and images (but only ones that are attachments), which plaintext isn't sufficient for. On the other hand, I want _only_ that, and notably they all provide a nice and obvious client-side failover for TTY software without requiring attaching a 2nd copy of the text.
HTML in email helps readability, titles, lists, tables does help the recipient.
[deleted]
Nothing that cannot more elegantly be solved by using MarkDown ...
... or common sense.
... or common sense.
I don't want to parse Markdown when I read emails.
(and I don't have common sense either)
(and I don't have common sense either)
As long as the varient of Markdown supports tables, vanilla markdown is laking in that area.
Which e-mail client can render markdown?
I take the hybrid approach:
<b>Hello</b><br>
...<br>
...<br>
<em>Thanks!</em>Let's fix your comment:
% I'm all over for using cutting edge CSS solutions but when it comes to HTML email, I'm just:
% <h1>Hello</h1> % <p>...</p> % <p>...</p> % <em>Thanks!</em>
Let's make two billion dollars great again. Unpolitically.
% and it's done :)
Die poor.
% I'm all over for using cutting edge CSS solutions but when it comes to HTML email, I'm just:
% <h1>Hello</h1> % <p>...</p> % <p>...</p> % <em>Thanks!</em>
Let's make two billion dollars great again. Unpolitically.
% and it's done :)
Die poor.
So now imagine that you would like to add <button>.
Well... Good luck with shady VML tricks!
https://buttons.cm/
Well... Good luck with shady VML tricks!
https://buttons.cm/
Buttons in emails sound fishy :) I would just use an inline styled anchor.
Why using plain text is better:
- readable under any mail client and any text editor
- smaller size files
- safer
- better accessibility and compatibility with screen readers
- readable under any mail client and any text editor
- smaller size files
- safer
- better accessibility and compatibility with screen readers
I don't get why plain text would be more accessible than a well-formed HTML email. A screen reader could say "this is a title", "this is a list item".
In plain text, what do you get? "dash bla bla"? Though I hope screen reader are more intelligent than that, but it seems like a more complex problem than just using information given by a well-formed HTML text.
In plain text, what do you get? "dash bla bla"? Though I hope screen reader are more intelligent than that, but it seems like a more complex problem than just using information given by a well-formed HTML text.
Give people HTML and most e-mails will be a complete undecipherable garbage on the markup level.
Basically almost everyone puts anything there so that they get some visually pleasing result, the markup semantics be damned.
One would think that lack of features of various mail clients would lead to using the lowest common denominator of some basic tags like b, i, a, hr, and maybe img.
Not so in reality.
One bank I've seen e-mails from even abuses invalid parsing of HTML comments, to produce whatever insane result someone somewhere dreamed up, like this:
(Experiences from writing a web mail client to be used in a real world.)
Basically almost everyone puts anything there so that they get some visually pleasing result, the markup semantics be damned.
One would think that lack of features of various mail clients would lead to using the lowest common denominator of some basic tags like b, i, a, hr, and maybe img.
Not so in reality.
One bank I've seen e-mails from even abuses invalid parsing of HTML comments, to produce whatever insane result someone somewhere dreamed up, like this:
<!--><div style="some:crap"><!-->...
(Experiences from writing a web mail client to be used in a real world.)
Well, plain text doesn't require smart or sophisticated screen readers. Anything that can read text will work, that's why plain text emails are more accessible. Not every person that needs screen reader can afford some top of the line device.
A "well-formed HTML email" is about as common as a "functioning Communist state". I'm sure they're both great, and I'll let you know when I see one.
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.
> (Because every test is done manually, some features might not have been tested on every email client.)
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.)
> (Because every test is done manually, some features might not have been tested on every email client.)
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.)
I would guess that there are certain unforeseen interactions between failed implementations, maybe certain ones prevent emails from being rendered etc. I suppose those could be documented as well, but would take a lot of extra effort to figure out the combinations.
I'm guessing the feature list has grown over time. Each time more features are added, 58 clients need to be checked.
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
[1]: https://github.com/peterbe/premailer
[1]: https://github.com/peterbe/premailer
I don't think premailer provides any solution for figuring out what CSS works with outlook or altering CSS to work with outlook? It mostly just, as it says, "Turns CSS blocks into style attributes". That is a different problem/issue than OP is about.
I'm starting to run into the emails themselves just being too darn large (over 1mb). There's no gzip with email.
Why use HTML in emails though?
Because mere humans like to have images, colors and text formating in emails.
Because nothing else has anything beyond the most minimal support for right-to-left languages.
Aside: it's nice that the site checks <bdi>, but dir/direction is much more widely used in practice and should be added.
Aside: it's nice that the site checks <bdi>, but dir/direction is much more widely used in practice and should be added.
It's convenient for underline, bold or italics in some long winded messages.
That's why we have lightweight markup syntaxes like markdown.
Markdown is a lightweight syntax for writing and generating HTML, like BBCode. It's not an alternative syntax to HTML.
Markdown is designed to be readable without encoding it as HTML though, so is nicely readable on old email clients too.
Sure, but then it's just plain text, and plain text could be perfectly legible before Markdown came along.
The only tangible benefit Markdown provides is letting people write HTML who don't like the aesthetics of HTML tags.
The only tangible benefit Markdown provides is letting people write HTML who don't like the aesthetics of HTML tags.
The idea is that it gives a standard for semantic markup that can be read as plain text. Lists, highlighted text, block quotes, etc. that is all plain text but easily parsed by humans.
I want to write mathematics in my emails all the time, and sometimes I want to communicate with people who don't yet know LaTeX.
HTML emails are a blessing. Receiving them allows me the ability to quickly glance at an email from an unexpected sender and immediately recognize it as a marketing email or cold sales, and send it to the spam folder without needing to read a single word.
Have been using Cerberus since 2016 for responsive emails with no issues:
https://github.com/TedGoas/Cerberus
https://github.com/TedGoas/Cerberus
This is a gem. I created an in-house mail builder based on its styles.
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.
Actually, I'd prefer if they added something like CommonMark and removed HTML.
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.
https://useplaintext.email
https://useplaintext.email
Just wondering, what's your opinion on the flowed format? I like it when the recipient uses a smaller screen geometry (phones can be <80 col). And sadly, that page doesn't track this feature...
I've yet to use any software which supports flowed, as a sender or recipient. As a recipient I appreciate when flowed is done right and properly hardwraps lines as a fallback. Seems like a decent compromise.
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.
> We desperately need for someone to finally win this mail client war and some standardization to emerge.
Like all things, we need competition in this field. The Gmail web interface is already the most prevalent mail client. Because of this, Google can and has already started controlling the future of email. Just look at AMP for email. I agree with standardization, but not by having only one email client.
Like all things, we need competition in this field. The Gmail web interface is already the most prevalent mail client. Because of this, Google can and has already started controlling the future of email. Just look at AMP for email. I agree with standardization, but not by having only one email client.
Competition is good, but competition creates segmentation, and with mail clients it's already far more crazy than browsers ever were. There are huge differences even between the different versions of the same client, especially across the different platforms - and people still use some really old Outlooks, so you can't ignore them. I've been doing web dev for a long time, ever since the IE4 (there was still NN back then), so I've been through all the craziness of the browser differences, but this is far worse as many clients are rewriting the html and limitations are super strict, you have to inline everything and use all kinds of css hacks.
IIRC CampaignMonitor has had a pretty good resource for many years: https://www.campaignmonitor.com/css/
yes, them and Email on Acid were the best sources on what's supported where.
Isn't it time for desktop clients to embed a real rendering engine? The isolation on them has reached a good level.
Every GUI desktop client I'm aware of embeds a real rendering engine. The difficult one is Outlook, because Microsoft made a conscious decision that compatibility between Outlook and Word was more important than between Outlook and web browsers. I believe the Word/Outlook HTML engine was based on IE 5.5.
The MSO renderer is a buggy and incomplete implementation of HTML 3.2, and I think high-DPI support is the only change of any substance at all in the last twenty years.
They could switch depending on Doctype- it wouldn't be the first time they've done it...
Apple's mail clients use Webkit under it all, basically Safari, that's why the scores are so high. It's actually an interesting story, In the book `Creative Selection`, Webkit and Apple Mail were really Chicken and Egg-like, with the two being developed for each other with the HTML Editing logic in Mail being the basis of all text fields in iPhone.
Thunderbird had the best rendering engine of them all last time I checked with the microsoft ones being worse. Even if they did embed a real rendering engine you still have to deal with all those people using office 2010
KMail uses QtWebEngine, which is effectively Chromium.
This resource would be more useful if it also indicated support for relevant email-only features:
* Blocking of remote resource loads
* Which resources can be loaded via multipart/related and cid: links.
* How are doctype-less HTML bodies loaded
* "Leaking" of HTML parts in a multipart/mixed message
* Blocking of remote resource loads
* Which resources can be loaded via multipart/related and cid: links.
* How are doctype-less HTML bodies loaded
* "Leaking" of HTML parts in a multipart/mixed message
This is good! I have searched for this actually.
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.
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.
I think that would be difficult to calculate accurately. We can collect user-agent statistics from browsers but mail clients don't have an equivalent when reading mail.
A rough estimate would satisfy me at least. Seems Litmus has farily broad statistics from 823 million opened emails: https://emailclientmarketshare.com/ (August 2019)
It's probably strongly tilted towards email clients which don't block external images by default, and email clients used by people who are more likely to be targets of a marketing campaign (i.e. richer 1st world people).
[deleted]
A number of email clients will add a header line that identifies them to every email that's sent.
The problem is that you don't care about email clients as distributed by senders, you care about the distribution of recipients. Especially if you're a marketer trying to gauge what kind of HTML you can use in your email.
The only people who can really use the headers to identify which email clients are in use are people who maintain very large ISPs. Although, even then, keeping track of the results of the IMAP ID command are probably more useful.
The only people who can really use the headers to identify which email clients are in use are people who maintain very large ISPs. Although, even then, keeping track of the results of the IMAP ID command are probably more useful.
Not one mention of FLOW TEXT Issues.
> Nor, the MS quoting issue.
-G
> Nor, the MS quoting issue.
-G
[deleted]
You can use tailwindcss for emails as well https://maizzle.com
This is very cool. One feature I'd like is the market share report that caniuse has for each listing.
I currently rely on https://emailclientmarketshare.com/ (by Litmus) for this but if someone's aware of a better data source, I'd like to know.
I currently rely on https://emailclientmarketshare.com/ (by Litmus) for this but if someone's aware of a better data source, I'd like to know.
Tracking market share of email clients is very difficult. To capture browsers, all you have to do is beg server logs off of the largest websites, and you can derive statistics for your own user base by crawling your own server logs.
But email? The usual way statistics are collected are by embedding 1×1 tracking pixels in email messages and noting who requests those images. But that will undercount any email client that has the option to refuse to load remote images, especially any one that turns that option on by default (such as Thunderbird). Another way is to look at the headers of large corpora of email, but the only ones that are publicly available are going to be mailing list archives, which will tend to have a more skewed distribution.
But email? The usual way statistics are collected are by embedding 1×1 tracking pixels in email messages and noting who requests those images. But that will undercount any email client that has the option to refuse to load remote images, especially any one that turns that option on by default (such as Thunderbird). Another way is to look at the headers of large corpora of email, but the only ones that are publicly available are going to be mailing list archives, which will tend to have a more skewed distribution.
I got to use BBN Diamond https://tools.ietf.org/html/rfc910 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.
[1]: http://sgmljs.net
[1]: http://sgmljs.net
I don’t see emoji covered yet, but I have had real issues with gmail not recognizing some Apple-okay emoji or displaying them with extraneous symbols.
Hope KMail and Protonmail get added as well.
I needed this 14 years ago
Learn about email related information networks
Such a great idea. Thank you!
[deleted]
For me discovering https://mjml.io/ 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.
It supports responsive email designs and has many examples which you can alter to your needs.
You can see the power here: https://mjml.io/try-it-live the basic 15 line example expands to 188 lines of html so that it looks the same everywhere.
It supports responsive email designs and has many examples which you can alter to your needs.
You can see the power here: https://mjml.io/try-it-live the basic 15 line example expands to 188 lines of html so that it looks the same everywhere.
Have you tried https://zurb.com/ink/index.php ? Seems similar, and a bit older
They are very, very different things.
Zurb Email is like Bootstrap/Zurb Foundation, for email. They are common styles that apply to your HTML.
MJML, in other hand, is not HTML. You write MJML, instead of HTML, and it compiles to HTML.
It's really fantastic.
Zurb Email is like Bootstrap/Zurb Foundation, for email. They are common styles that apply to your HTML.
MJML, in other hand, is not HTML. You write MJML, instead of HTML, and it compiles to HTML.
It's really fantastic.
With ink (well, inky) I write an email using things like "row", "columns", "spacer" etc. and then a process converts those to HTML+CSS, then another inlines the CSS.
It doesn't seem much different to me.
It doesn't seem much different to me.
User feedback: I fiddled with this for a few minutes and could not make heads or tails of it.
hi good days
HTML E-Mails are a security nightmare, even if "only" CSS is "allowed" and JS/iframes/external images are not loaded.