
Can I Email: ‘Can I Use’ for email - heidijavi
https://www.caniemail.com/
======
ktpsns
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.

~~~
cygned
No markdown, but we had success with this one:
[https://mjml.io/](https://mjml.io/)

Try out the online examples.

~~~
adamredwoods
We use
[https://foundation.zurb.com/emails.html](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.

~~~
justinator
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.

------
ht_th
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.

~~~
inops
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.

------
shrumm
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!

~~~
gotts
MJML is great.

I think that [https://www.caniemail.com](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.

------
LeonM
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](https://templates.mailchimp.com)

~~~
canofbars
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

~~~
ameen
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.

------
gondo
I've used this guide to navigate email styling nightmare:
[https://www.campaignmonitor.com/css/](https://www.campaignmonitor.com/css/)

And this tool to test emails before sending:
[https://litmus.com/](https://litmus.com/)

~~~
ukyrgf
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.

------
svat
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...](https://developers.google.com/gmail/design/reference/supported_css))
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.

~~~
ktpsns
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.

~~~
svat
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. :-)

------
segfaultbuserr
> _Can I email_ plaintext __?

> _No results found. Why not suggest this feature to be added?_

It's worth sending a pull-request.

~~~
jolmg
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](https://tools.ietf.org/html/rfc1049)

[2] [https://tools.ietf.org/html/rfc767](https://tools.ietf.org/html/rfc767)

[3]
[https://github.com/hteumeuleu/caniemail/issues/23](https://github.com/hteumeuleu/caniemail/issues/23)

~~~
ainar-g
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.

~~~
segfaultbuserr
And imagine opening an E-mail that contains a PhD paper requires 15 minutes of
compilation...

------
grenoire
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.

~~~
ndidi
Everything that discourages designers from doing fancy things is good in my
book.

~~~
enraged_camel
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.

~~~
other_herbert
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?!

~~~
pbhjpbhj
Y̗̳̬͍̘͚o͘u͏ ͏̬̟̩h̦̕a̰̖͍̟v̧̯̜͉͙̖͖͉e҉̳̲̙͚̗̬ ̤͚͉̀w̢̫͎̮̼͇o̷̮̙̩n̪͙͎̠͔ ̻̮a̛̭
̡̪̤̻ͅp̵̭͇r̩͉į̬̺̭̯͍͙z̯͈͟e!͖̖͈̯

ie don't any mua let you use UTF8?

𝔻𝕠𝕖𝕤 𝕥𝕙𝕚𝕤 𝕨𝕠𝕣𝕜?

~~~
jraph
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.

~~~
thirdfail
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.

~~~
jraph
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.

------
sitkack
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.

------
bradley_taunt
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/](https://bradleytaunt.com/plain-
text-emails/)

------
marban
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.

~~~
mrweasel
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.

~~~
tatersolid
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.

~~~
Fice
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.

------
greyhair
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.

~~~
pembrook
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.

~~~
slrz
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.

------
tiborsaas
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>
    

and it's done :)

~~~
jorangreef
How about this?

    
    
      Hello
      ...
      ...
      Thanks!

~~~
tiborsaas
HTML in email helps readability, titles, lists, tables does help the
recipient.

~~~
DocTomoe
Nothing that cannot more elegantly be solved by using MarkDown ...

... or common sense.

~~~
lolknuth
Or you could say at a plaintext email first paragraph: You have to use your
own fun/gun for this, and just type in plain text.

~~~
DocTomoe
... which is perfectly ok, because MarkDown nicely degrades to plain text.

------
6d6b73
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

~~~
jraph
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.

~~~
megous
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:

    
    
      <!--><div style="some:crap"><!-->...
    

Which is straight up invalid HTML, that sanitizing parsers like caja will
reject. I had a fun of telling a client, that I will not purposefully break
parsing algorithm of a HTML sanitizing parser just so that their customers can
read mails from their bank.

(Experiences from writing a web mail client to be used in a real world.)

------
akuji1993
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.

------
skissane
> 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.)

~~~
grenoire
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.

------
Existenceblinks
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.

------
awestroke
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](https://github.com/peterbe/premailer)

~~~
jrochkind1
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.

------
Lxr
Why use HTML in emails though?

~~~
jobigoud
It's convenient for underline, bold or italics in some long winded messages.

~~~
swalladge
That's why we have lightweight markup syntaxes like markdown.

~~~
krapp
Markdown is a lightweight syntax for writing and generating HTML, like BBCode.
It's not an alternative syntax to HTML.

~~~
Moru
Markdown is designed to be readable without encoding it as HTML though, so is
nicely readable on old email clients too.

~~~
krapp
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.

~~~
swalladge
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.

------
sexy_seedbox
Have been using Cerberus since 2016 for responsive emails with no issues:

[https://github.com/TedGoas/Cerberus](https://github.com/TedGoas/Cerberus)

~~~
andrei_says_
This is a gem. I created an in-house mail builder based on its styles.

------
hiccuphippo
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.

------
Sir_Cmpwn
No, you should not use any of these. You should only use plain text.

[https://useplaintext.email](https://useplaintext.email)

~~~
MayeulC
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...

~~~
Sir_Cmpwn
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.

------
ivanhoe
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.

~~~
andrewkdinh
> 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.

~~~
ivanhoe
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.

------
lozenge
Isn't it time for desktop clients to embed a real rendering engine? The
isolation on them has reached a good level.

~~~
jcranmer
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.

~~~
chrismorgan
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.

------
jcranmer
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

------
volument
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.

~~~
longwave
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.

~~~
volument
A rough estimate would satisfy me at least. Seems Litmus has farily broad
statistics from 823 million opened emails:
[https://emailclientmarketshare.com/](https://emailclientmarketshare.com/)
(August 2019)

~~~
yyyk
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).

------
ggm
Not _one_ mention of FLOW TEXT Issues.

> Nor, the MS quoting issue.

-G

------
upofadown
>CSS

The last thing I want is for someone else to control the appearance of my
email...

~~~
ken
Good news! The "C" means you can have the final word.

------
fouc
You can use tailwindcss for emails as well
[https://maizzle.com](https://maizzle.com)

------
asadkn
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/](https://emailclientmarketshare.com/) (by
Litmus) for this but if someone's aware of a better data source, I'd like to
know.

~~~
jcranmer
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.

------
ggm
I got to use BBN Diamond
[https://tools.ietf.org/html/rfc910](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.

------
tannhaeuser
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](http://sgmljs.net)

------
WoodenChair
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.

------
Avamander
Hope KMail and Protonmail get added as well.

------
philmander
I needed this 14 years ago

------
guhbml
Learn about email related information networks

------
chrisnager
Such a great idea. Thank you!

------
Thomaschaaf
For me discovering [https://mjml.io/](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](https://mjml.io/try-
it-live) the basic 15 line example expands to 188 lines of html so that it
looks the same everywhere.

~~~
mfontani
Have you tried
[https://zurb.com/ink/index.php](https://zurb.com/ink/index.php) ? Seems
similar, and a bit older

~~~
emilsedgh
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.

~~~
mfontani
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.

------
droithomme
User feedback: I fiddled with this for a few minutes and could not make heads
or tails of it.

------
Melankolik-95_
hi good days

