to

Hilarious anecdote about this website: the owner once said there are tons of entries in the usage log of people misunderstanding the purpose of the website and inputting celebrities names to try to email them. :D

At first glance I was trying to figure out what this is about but, so far nothing. It's "like caniuse but for email content", ok but, what is caniuse? I don't know if it is worth but, before launching something new, I wish everyone consider to publish a brief section to explain to the average person what this is about.

that's a startup idea. and the answer to the "can i email...?" will be always a static page the says "no".

there is money to be made here.

That's not true and a very much defeatist view. Yes, you can talk with people if they're willing to listen and maybe even respond. Yes, even if they're extremely popular already. Even if they're richer than you.

The lower the score, the better. I know many who have a policy of "emails must be in plaintext only, with no attachments unless agreed to in advance; everything else gets deleted automatically."

My point, though, is about confirmation bias. Most people don’t know a lot of people who turn on plaintext email as a point of habit.

It might seem like I’m criticizing the guy, but the thing is, there is a very real problem where people are looking at this from their own tech-forward perspective when this is a topic that affects many more people.

I believe there are two points in the message :

- A normative one : the less is supported, the better.

- A descriptive one : many (not indicative of any share) of their relations actually do that.

None of the points is telling about their relations, aside from, maybe, not having many friends in adtech.

Average people tend to use what they have, I have zero "average" friend trying to get more supported features than there currently are.

And, by the way, most of my friends do not use html/CSS directly, or even indirectly use it besides some bold, coloring or the random photo attachment. Zero of them know caniemail.com, and, if they understood the point of it, zero of them would want or need it.

Average people seeing html in their mail doesn't mean they have an opinion on it, or would want more of it if they were told honestly what it does and who abuses it.

> This was not my point and you know it.

No, but that was mine in the message you answered to.

> The average person consumes HTML email.

And I'm not sure the average person cares about receiving elaborate emails with spy pixels and advanced use of CSS either.

For another interesting datapoint: Of the plaintext-only and plaintext-strongly-preferred people I know, somehow almost all of them are German. I wouldn't call them "tech-forward" either, as many of them are specialists in other fields.

...and before the inevitable questioning I'm going to receive: no, I'm not German, and I know more people who aren't, with similar plaintext preferences.

I disagree. I wish I had more people that fit that filter. Email is broken and just a platform for spam. Even if it might be from someone that I purchased something from once or even regularly, if I did not select a check box to opt-in to receiving your email, it is spam.

It's 2024. Emailing large file attachments is about as old and busted as FTP. There are so many other services to "share" large files. Attachment to email was such a kludgy hack in the first place just shows it was only the best worst idea waiting for better solutions. We have them now.

As someone who works very regularly in email, it really bugs me that every time I see a thread about this topic in Hacker News there seems to be this confirmation bias that this is how the average person uses email in the wild, and I’m just trying to make the point that “Hey, this is a strong minority viewpoint.”

I get that y’all don’t like HTML email, but the fact of the matter is, that was a battle lost 25 years ago, and we need to figure out how to keep what we have working for people who don’t even know how to set plaintext email.

That’s what this particular tool is for.

By this standard, we should go back to Lynx, because rich web browsers are way more dangerous than this extreme edge case that this guy invented because he doesn’t like HTML email.

First: I run a popular newsletter that uses custom HTML theming and CMS customization. I don’t work in marketing. I just genuinely think HTML in email is actually a value add. Not everyone you disagree with works in marketing.

Secondly: The problem you’re pointing at is bad implementation of standards, which is entirely on Microsoft and Google. (Mostly Microsoft.) The reason HTML doesn’t work well in email is because of bad prioritization, which has led to kludge upon kludge.

> The reason HTML doesn’t work well in email is because of bad prioritization, which has led to kludge upon kludge.

Honestly the main reason is that HTML/CSS expanded well over the creation of documents into the creation of apps. Email content does not really need all of that, it will always only support a subset of that causing confusion.

That said, the lack of standards is definitely the worst aspect of all of this and resulted in the current absolute chaos

A website like this is not required. It's just nice to have. Somehow we've managed to use email without this website it for the decades that email has supported HTML.

Caniuse exists too, does that mean HTML and CSS are broken? Nah, it's just a useful resource to help people decide what tradeoffs to make.

There's a vast spectrum of HTML email.

Most people use it in the "bold a few things and make a few words into a link" side of things; more like the old .RTF format. The caniemail.com stuff is for the more complex stuff that might be better left to websites.

> clearly, it's not working if a website like this is even required. you say it is HTML compatible, then continue to tell me things in HTML are not valid for use. you say it can use CSS, then continue to tell me all of the valid CSS that cannot be used. so I'd suggest s/working/working*/ and then define the caveat as required.

That is not the point though.

The point is that the vast majority of people prefer transactional / marketing emails in rich formatting. They understand them better, they prefer interacting with them, it results in a better overall user experience.

Who creates all those transactional / marketing emails in HTML? Developers. Plenty of them.

All of them are in a difficult situation because writing HTML for sucks. It REALLY sucks. Tools like this one help them (the developers!).

Not using HTML emails is not an option in this field. It will never be as long as the average user (AKA the average customer) responds well to rich formatted emails.

I don't reject HTML email, but I always have my client set to read plaintext. 99% of the time, the worst thing that occurs is simply some garbled hyperlinks for a verification email or similar.

Personally, I don't have any need for HTML email in my daily life, and the only emails I occasionally get that are very obviously 'broken' in some way in plaintext mode are usually marketing emails or other messages I don't want to read in the first place.

So, I figure, may as well keep it disabled since plaintext is more consistent and easier to read, and there is significantly less surface area for exploits when you don't need to bundle half a browser to view a couple of paragraphs.

There's a good case for expanding slightly on plaintext. It's not just decorative - some usecases like Right-to-Left or lists or linked are helped by a little markup, and HTML is good enough.

The problem is going overboard on CSS (maybe none should be allowed) or allowing any javascript at all. I can't recall any email security issue ever which is HTML only without any CSS or javascript.

I know at least two people who send emails where the HTML version is either blank or tells the recipient to stop using a bloated client, and the actual email content is in the plaintext fallback. I think I had to look at the email source in thunderbird to read them.

When I look at the features gmail doesn't support, I see things like "display: none", animation, and other kinds of css which arguably shouldn't be part of an email. The basics are there, so that makes high ranking not necessarily a good target.

Most popular only because it was included with the OS and most IT departments did not allow use of other browsers. Just because it was the most installed does not make it the most popular. There was an old saying, "Internet Explorer: the most used browser to download another browser."

IE 4 and 5 were pretty good. ActiveDesktop was pretty cool. XMLHttpRequest turned out to be revolutionary.

It was only after triple whammy of Netscape being unable to further compete, the dotcom crash and the antitrust suit against Microsoft's integration between Windows and IE that IE got deprioritized by MS and slowly turned into the underfeatured mess every developer hated.

This take is pretty revisionist. IE4 wasn't good, ActiveDesktop and ActiveX were either useless or actually bad. AJAX was probably the only good thing out of IE, and I would not dare to call it an happy accident but I'm tempted

Although Netscape was even worse (if you resized the window, it reloaded the whole page), and IE for Mac at the time had the best CSS support out of any browser (it was a different renderer from IE Win). I did a lot of bouncing between browsers (Netscape/IE/iCab/Opera) back then until Mozilla came out and wiped everything else out.

I remember hearing stats about the continued high numbers for IE, but a lot of those numbers were attributed to pirated copies of XP being used in China. Maybe it was why IE6 seemed to hang around as high as it was. Just a clarification of the numbers that I found interesting.

It's not a like it's a vote. Most people didn't choose it. They had it because their corp uses Windows, and Windows came with IE, and IT did not allow other browsers.

You're being a revisionist. The claim that it wasn't popular is just dumb. For years it was simply superior to all other browsers (both technologically and users liking it).

A fully-featured HTML "document" is really an application, not a document at all, so it makes sense that mail clients limit support. But this fragmentation makes me yearn for a real standard here, an official non-application subset of HTML that doesn't allow fetching remote resources or executing code. Just a document format with embedded media, animations, styling, etc.

An .epub file is in a lot of ways what you're asking for (it's HTML-based, it's designed to package inline media such as images and provide fallbacks if the client can't/won't make remote requests, it has limited/no scripting capabilities), and you might find it interesting to peruse its specification[1].

[1] https://www.w3.org/TR/epub-33/

Quite honestly, people have no business sending me code to execute or resources to fetch.

I get that adtech is interested in using my email as their billboard, but they can fuck right off. Plaintext + attachments or gtfo.

That's usually my default answer when my design team comes to me with a request for email template updates. "No. Basic formatting only. If you are feeling frisky, tables. Nothing more"

Dark mode support in email is one of the most frustrating things I’ve dealt with as a frontend dev who’s been coding since the IE6 days.

Basically you have to accept that you must only implement a light mode design and choose colors that will look okay when automatically inverted by all of the shoddy dark mode email client implementations.

Gmail is one of the worst offenders. You have zero recourse for picking your own colors for dark mode.

The new Outlook desktop client is awful, but there's one silver lining and it's the retirement of the even more awful Word HTML renderer.

HTML email was such a tragic mistake.

I think the whole mess could have been averted if Markdown had been invented about twenty years earlier.

Is this intended as sarcasm? Markdown renders to html, it's an authoring syntax that happens to be readable in it's "code" state. How would it solve email?

The real issue is bespoke rendering engines instead of just using a rule of "everything the current browser can do, but no js".

Markdown gives most people >95% of the formatting they want to do.

It's easy and fairly intuitive to write (most of it, anyway).

It's easy to read in different formats and ways (HTML, plain text).

It doesn't add highly complex rendering issues. I've worked on two email clients in the last ten years, and the amount of weird HTML some send is just bonkers. Is

in emails crazy? Yes. Do you need to deal with it? Also yes.

It's not. Markdown is markdown. It can render to HTML, but that's a different thing. I struggle to understand why this is even a point of contention.

That's quite the pivot from "markdown is HTML". But no, it probably shouldn't support HTML tags, or support it with limits. And maybe also a few other things like #-headers also shouldn't be supported as it can be too easily to do by accident. All of that seems pretty obvious in all but the most aggressively pedantic reading.

If your C code end up like that, yes:

``` #include

int main() { /* my software in ASM */ __asm__ ( [......] );

    return 0 ;

} ```

And you are pretty sure this is pretty much what would happen with markdown in emails if it ended up being mandatory. You would end up with emails entirely made of html.

If emails could be marked up with the subset of HTML that Markdown is able to generate without having inlined HTML tags, email markup would be so pleasant. Just bold/italics, some headings, tables, properly flowing text, code blocks, horizontal rule, links, and images.

you just need gemtext. Bold/Italics can be done with unicode, no need for a markup language.

Images can just be links and it would be a setting on the client to open it or not. Like what the Lagrange gemini browser does: it lets you click on a link to an image to load it.

I would argue that even tables are superfluous, you could put a csv file in a block quote and people's clients could just render it optionnally.

Not in the slightest.

You can’t make elaborate layouts with Markdown. You can’t obfuscate text in images or make hidden links or inject JavaScript.

Just some basic text styling (headers, italics, bold type), and images. Everything necessary to make a well-formatted message — which is what email is supposed to be — instead of mailing a web page, in a medium that hasn’t been refined for quality and safety like modern HTML+CSS has.

Yes, this. Many more would be fine with HTML email if it didn’t work like IE6—and honestly, the only reason it does is because of decades-old enshittification that we failed to address at the time.

I can't figure out how to use it.

When I enter "Test" rel="nofollow">https://example.org>Test" it says "No results found. Why not suggest this feature to be added?".

When I enter "" I get "AMP for email", "BIMI", "accent-color" and lots of other CSS attributes starting with "a" as result.

When I enter "a" I get the same as above.

How do I check if I can email the HTML Anchor tag? The input says "HTML, CSS, ..." but it doesn't seem to understand HTML unless I'm doing it wrong?

LOL ok that was just a really unfortunate coincidence. I used the tag because I knew it would/should be supported everywhere so wanted to test the website with an input where I know what response to expect :)

Huh, I didn't really fully understand that about SVG. Thanks for the info.

From what I'm reading, it seems that from inside an SVG script, you can call out to javascript functions of the parent page? That seems kinda surprising, I'm sure there are security policies around it, but it means that there are potential security and performance risks/considerations around hosting and serving SVG files that I didn't realize existed.

The comment you’re replying to is misleading. SVG supports JavaScript but only if you load the SVG directly in your browser or inline it fully into the DOM. Using it as a normal image tag, by reference or with inlined data:, it’s inert and harmless from a JavaScript perspective.

However, for a long time browsers were susceptible to denial of service attacks from maliciously crafted XML files, which SVG could exploit. (“Million laughs”). This doesn’t work in current versions but it might be a reason that SVGs are rejected.

Rendering HTML emails in the browser is rather tricky business, because HTML/CSS isolation mechanisms are non-existent or come with a lot of caveats. You want to make sure your layout doesn't get screwed because of some bonkers HTML/CSS but you also don't want the intended layout of the email to be completely screwed.

It's been a long while since I worked on this, but I was always very hesitant to make changes here, because we knew that our current thing worked for almost all customers, and you never knew what changes would break what.

We dogfooded our own client, and at some point a change I made broke the automated SIDN (which manages .nl TLD) emails. I forgot what exactly it was, but they did some really weird stuff. You can't just shrug and say "oh well, that's just crazy, fix your emails" because people do need those emails and getting these types of organisations to take action is like moving a mountain.

Isn't AMP considered an antifeature these days? Last I heard even Google had abandoned it — but this is outside my zone of expertise, so I might be wrong?

AMP for email is a bit different of a beast. It works a lot differently from the web version and is used essentially to add interactivity to the email. If you use Google Docs, it’s what allows you to directly reply to a comment in your inbox.

You maybe underestimating the number of people that use things without knowing what said things do, so those things just continue to live and never get migrated away from use.

MJML is better than most but remember every templating language has a footprint.

When possible reduce your html code weight to the bare bones minimum. Nothing too fancy. Keep it logical. After a bit of practice it’s actually easy and in my opinion often faster than MJML (For example MailJet. Don’t even get me started on Klaviyo.)

Even with minimal coding/hmtl experience you can run your code through GPT-4/Bard.

Bonus for including custom instructions such as “transactional intent”, Bayesian/heuristic filtering, coded for users with poor digital accessibility, under-served internet users, etc.

Even with the best domain domain/ip reputation without a positive engagement history specific to that user you will often land in promotions/other tab and not the primary tab for new users with a heavily weighted creative.

Remember you want to mimic “an email from Grandma” while maintaining some degree of control of visual design.

Or if that’s too complicated just keep your subject line under three words and all lowercase.

Flashbacks to making a nice email template for a company only to find out their entire client list used outlook from a decade earlier and could just about render plaintext. There was no point in me even showing up.

I use plain text, and I even enable "block external image" on the client, and I would advise others to do the same, because there is just too much phishing with email..

> Apple Mail (iOS) : 266/284

> Gmail (Android) : 111/284

Interesting corrective to the “Apple is holding back HTML” narrative that appears so often on HN.

Is there something like this for features techies might care about? Like some sort of guarantee of at-rest encryption, SMTP/IMAP/POP/etc support, end user encryption, reasonably fast search, backup/restore, etc.

GNOME Evolution and Thunderbird, at least last I used it, have abysmal search speed, taking seconds to search through a local DB of a few thousand emails. So they're clearly using search tech much inferior to a local DB with indexes.

I think it would be more useful to list the few CSS properties that all email clients do recognize. I don't mean to be flippant. I'm serious.

CanIEmail? The answer is generally no.

If you go to this page: https://www.caniemail.com/clients/

and select "check all", it'll show you the features that are supported by all the email clients, and separately, which features have mixed support.

These appear to be the few features supported by all clients:

- border-collapse

- font shorthand

- list-style-type

- cm unit

- em unit

- ex unit

- in unit

- mm unit

- pc unit

- % unit

- pt unit

- px unit

- vertical-align

- ~~element~~

-

element

-

to

elements

-

element

- element

-

element

-

element

- element

- element

- element
- valign attribute
- JPG image format
- PNG image format

（评论）
(comments)

to

elements
-
element
- element
-
element
-
element
- element
- element
- element
- valign attribute
- JPG image format
- PNG image format

（评论） (comments)

to

elements- element- element- element- element- element- element- element- valign attribute- JPG image format- PNG image format

（评论）
(comments)

elements
-
element
- element
-
element
-
element
- element
- element
- element
- valign attribute
- JPG image format
- PNG image format