What an excellent resource! (And yes Outlook is a pain and supports so very little!)
We've tried building email templates for notifications for our apps where I work, and it has typically been a pain. We have since swapped to using mjml (https://mjml.io/) to build the templates, and it's working wonders. The output seems the be the most compatible with all different devices that we've tested on.
The other tool we enjoy using is Litmus (https://litmus.com), which allows you to throw in an email template and see what it looks like on all kinds of apps and devices. Other thread here mentions https://testi.at/ as well, which we've also had success with.
All of these have been really invaluable to designing emails for our apps.
mjml looks really interesting, thanks for sharing. I wish there was a business reason for orgs to care about accessable and machine readable (I guess OCR is a thing now but still) emails.
I've been using Foundation for Emails[1] for the very small number of emails that I've worked on which required more than just a list of img tags, and I really appreciate it for existing because HTML emails have been stuck in ie6 web days.
> I wish there was a business reason for orgs to care about accessable and machine readable emails.
I hope the upcoming EU Accessibility Act will be enough for many organizations to finally make their emails accessible. I disable images by default in my email client, and some emails are pretty much empty without them, without providing any alternative.
> I wish there was a business reason for orgs to care about accessable and machine readable
Isn’t the whole point of sending emails to get the recipient to read them? If the recipient can’t read them, you wasted that money and captured no value. Possibly negative value because you just reminded the recipient of how annoying your website is. “Oh right, that vendor with the full-page modal that I couldn’t dismiss, or was it the vendor that had a pretty site that turned gray three seconds after loading for not discernible reason and wouldn’t let me click anything after that? I’ll just shop at Amazon next time even though they’re more expensive and vaguely evil.”
I assume most email client support email with both html and txt content. If they don't support html or configured not to display it, the txt version is displayed.
We have a html and txt template for each email we send. It's not exactly double the work, but it's appreciated by some of our customers.
I have my email client configured to display messages as plain text. A large fraction of emails that I receive have a text part that is empty or has some placeholder text. Also, senders often generate the text version by taking the HTML version and just stripping all tags, which means that all links are removed. I wish I could configure my client to ignore the text part completely, and instead to convert the HTML part to plain text, which is what it is doing already if there is no text part.
MJML is easily the best tool of its kind and I use it a lot. If anyone is trying to build emails in 2024, it's a major shortcut that helps avoid and mitigate some of HTML email’s biggest headaches.
the mjml components unpack to a very large number of html tags. so depending on how you structure the doc it can exceed the gmail doc size with a surprisingly small amount of content
While we‘re here I‘d also like to recommend react-email[1] which I‘ve been using for building emails for a while now. The components it offers are more than enough and it‘s definitely better than building mails with <!—MSO—> tags every five lines like we did back in my email marketing days.
Kind of. Though if outlook magically goes away we'll still make emails with <table> because most clients still do not support even flex-direction. Outlook is just exceptionally bad with stuff like width:100px working on table elements, but not on <div>, or padding working only on specific elements.
Holy shit all of those are awesome links, I'm working on an internal tool and i like to have clean looking notification and alert emails but its a FUCKING NIGHTMARE because everyone uses either Gmail or Outlook and both handle everything so poorly and... weirdly. And oh my god having to use tables... so many tables.
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 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.
I know for a fact that Gabe Newell, for example, reads all emails that people send him, and even responds pretty often. So I'm pretty sure other famous people do that
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.
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.
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.
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.
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.
That was a saying later in the game and among techies. Website usage stats indicate that in 2007 a solid 67% of people were using IE, and that didn't drop below a majority of usage until mid-2010.
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.
A quarter of Chinese web surfers were using Internet Explorer 6 twelve years after it was released. At that time, most online banking in China only supported Internet Explorer and derivatives.
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].
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.
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 <div style="position:fixed"> in emails crazy? Yes. Do you need to deal with it? Also yes.
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.
int main() {
/* my software in ASM */
__asm__ ( [...<insert your assembly code lines here>...] );
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.
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.
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.
You might have been unlucky searching for the a element that's really short. And very basic HTML would work everywhere.
But you might be more happy to go via the feature list: https://www.caniemail.com/features/
LOL ok that was just a really unfortunate coincidence. I used the <a> 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 :)
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..
And emails can totally be sent both as plaintext and HTML, so that the receiver can choose! I just don't understand why so many services only send a text/html version instead of both text/html and text/plain.
Quite a lot of services send both… and the text/plain version is completely different. They used to be the same many years ago, but then whoever is in charge of changing the email template only changes the text/html variant, and keeps the text/plain content stuck in the old times. It'd be almost funny if it wasn't tragic.
It is, although practically I don't really mind as my mutt is configured to filter text/html through elinks, so I see the content just fine. It's those other annoyances like tracking links that span a dozen lines that annoy me more. :-(
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.
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.
That's a completely valid opinion, and I prefer plaintext as well
But at this point, it's pretty clear that most non-technical people prefer emails with fancy text and graphics.
Personally, I'm just glad that email is a flexible enough medium to allow that. It's better than the alternative, where people moved to some closed, proprietary protocol behind like 20 patents that allows the same thing.
Is there any other common way we communicate over screens (aside from http) that has had the staying power of email for the general public? I think that's a testament to the sheer flexibility of it. The ugliness that people have contorted email into is a badge of honor IMO
> But at this point, it's pretty clear that most non-technical people prefer emails with fancy text and graphics.
And what percentage of e-mails from people / human beings have those things?
Certainly marketing e-mails have fancy formats, but I've rarely seen any person at a companies I've worked at use any kind of formatting: generally most folks hit reply and start typing with whatever the default is. Hardly any italics or bold, and forget about fixed width (for things like CLI commands in technical discussions).
Heck, even Slack messages these styles are hardly used (on my current team I use them the most since I know that Markdown so it's easy for me to throw in some **, //, or `` in my typing flow, so I can highlight hostnames, CLI commands, etc).
You must be joking. I write and receive emails containing lists, hyperlinks, or blockquotes all the time. I don't need the last flexbox technology, but some formatting is important.
Huh? You can paste if you have an image in your buffer, or drag-drop image files into an email in the Fastmail composer. I paste images into emails from screenshots almost every day.
(I'll take this report as a "we need to make it clearer you can do this!")
Very happy Fastmail user here! Would love if images could be resized in the webapp. For some reason most screenshots I paste in get scaled up to a very unwieldy size.
That's you. My work emails receives 25-50 real human a day. I get less than that amount in SMS in an whole year on my work phone. Even my personal email is significantly more email than SMS. SMS is dying and replaced with messengers e.g. Teams, Signal, WhatsApp, Facebook Messenger etc.
I understand if you are manager/owner you might be running comms via email. But internally all of that went to slack for good reason - lack of history is a feature, not a bug.
> I understand if you are manager/owner you might be running comms via email. But internally all of that went to slack for good reason - lack of history is a feature, not a bug.
I am neither manager nor owner. Just another 1x engineer. 75% of my comms run over email. 25% over Jabber.
Well you are not op to begin with and admit running a chat app which is has 99% chance of having better UX than email.
Email is good for having common interface. In my case it's ~abused in 99% of cases.
Also - you do not mention how much non-comms emails do you receive. While chat apps are fucky in terms of lock-in, lack of interop and tons of other things, lack of spam is nice.
> IMO, HTML was the worst thing that ever happened to email. Plain text content is the best content.
Your first statement might be true (it's debatable). Your second is definitely false.
Lets assume that HTML really was the worst thing that ever happened to email. Plain text content for email is still not the best content.
People want to:
1. Click on a link in the email, not fumble with copy and paste on their phone.
2. See decently formatted paragraphs and content with bold, italics and different font sizes for headings and paragraphs, not a wall of text.
3. See images in the email itself, not have to once again fumble around with copy and paste.
4. Correctly formatted bullet points, including sub-lists.
For all of the above, some sort of format is required. If we exclude HTML as a possibility, you're still going to have to need a format of some type, because the wall-o-text format is not a good UI.
1. all links are click-able at this point; what's more plain-text would force to provide just a link without all the tracking garbage
2. you can have paragraphs and headings... it's just a matter of structure - using html you can write a wall of text just fine
3. not sure if needed, besides you can attach images to plain text (though not inlining) or click-able links to external sources (at exact place)
4. still - easily do-able; it's a matter of particular editor tracking lists - for markdown editors it works just fine and in the end you virtually have a "plain text bullet list"... magic.
The most contagious/problematic issue is (3) and inlining - as I said, it's possible to attach anything but the location is lost. Probably something simple like anchor (again, markdown linking comes to mind) to indicate placement would be just fine...
> 1. all links are click-able at this point; what's more plain-text would force to provide just a link without all the tracking garbage 2. you can have paragraphs and headings... it's just a matter of structure - using html you can write a wall of text just fine 3. not sure if needed, besides you can attach images to plain text (though not inlining) or click-able links to external sources (at exact place) 4. still - easily do-able; it's a matter of particular editor tracking lists - for markdown editors it works just fine and in the end you virtually have a "plain text bullet list"... magic.
I think this comment displays the problems with plain text. I really couldn't have provided a better example.
As regards the counterpoints:
1. All links are clickable
Yes, and that's a bug. "http://www.example.com" should not be a clickable line. More to the point, it's not plain text anymore if the user gets something that has been interpreted and then rendered by the software.
2. It's not obvious how this should be done, and how it should reflow. You yourself failed to manage this in your reply, which I consider a good argument for why plain text is a poor UI.
3. Who cares whether you need it or not. The reality is that the clear majority of people use it!
4. Once again, if we're talking about a specific format that gets rendered into something readable, then it's not plain text anymore.
I'm arguing against the GPs assertion that plain text is the best format, not that markdown is insufficient.
> More to the point, it's not plain text anymore if the user gets something that has been interpreted and then rendered by the software.
Arguably it is. It was sent as plain text and received as plain text. The fact that the recipient's software goes through and interprets that plain text and does something when it detects an URL in it doesn't change that. If the recipient were to use some other software that doesn't do that, they'd see... Plain text. Because that's what it is.
> Arguably it is. It was sent as plain text and received as plain text. The fact that the recipient's software goes through and interprets that plain text and does something when it detects an URL in it doesn't change that. If the recipient were to use some other software that doesn't do that, they'd see... Plain text. Because that's what it is.
Exactly like .... the subset of HTML we see in emails?
I have not yet gotten an HTML email that, when displayed in plain-text, was unreadable. Neither, I suspect, have you.
> what's more plain-text would force to provide just a link without all the tracking garbage
I'm glad that you never ever received any link to some derivation of st.es.rui.tracking/bzzz/pfrrrrt?campaign=hn that hide the real link, but in the real world, that's how tracking is done. Plain text doesn't prevent anything.
> not sure if needed, besides you can attach images to plain text (though not inlining) or click-able links to external sources (at exact place)
For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.
You want to argue that plain text is better, but your arguments are that plain tex, are better for you. Don't make the mistake to assume that your specific experience is a workable average.
Please don't conflate adopting stupid solution to a problem that goes overboard (HTML) with equally stupid being stuck in shell and building stuff and using CLI...
PS. I assume all your github readme.md are all in full-blown HTML sprinkled with tracking links? :P
> I'm glad that you never ever received any link to some derivation of st.es.rui.tracking/bzzz/pfrrrrt?campaign=hn that hide the real link, but in the real world, that's how tracking is done. Plain text doesn't prevent anything.
That's the thing - I do get lots of them. In the age of html+plain and abuse of tracking (because it's so easy to hide with html), plain text version is just littered with this nonsense...
For example I just got notification from allegro.pl (shopping platform) and all links have that:
As for attachments - obvious exaggeration to dismiss actual issue: bravo…
> You want to argue that plain text is better, but your arguments are that plain tex, are better for you. Don't make the mistake to assume that your specific experience is a workable average.
Don't assume that someone using HTML actually do it conciously or is glad to receive it in that form because average user doesn't complain about it
So you're agreeing that plain text doesn't prevent tracking ? And that advocating for it won't solve the problem ?
> As for attachments - obvious exaggeration to dismiss actual issue: bravo…
No, the issue is that you can't tell everyone to "just upload the picture somewhere and put the link in the middle", that's unreasonable. That is the issue. HTML solves an issue.
> Don't assume that someone using HTML actually do it conciously or is glad to receive it in that form because average user doesn't complain about it
Average users want formatting. Plain text doesn't provide it. HTML for emails sucks, but plain text isn't a solution to that.
> Regarding 1. it's up to the client to parse and highlight links in plain text.
If the client is interpreting the content and then displaying its interpretation to the user, then it's not plain text anymore, is it? It's a format; in this case it's a poorly-specified, ad-hoc format and broken format[1] that is worse than simply having a reduced ad-hoc HTML format.
Just like HTML is "plain text" which is interpreted by the client and that interpretation is displayed to the user.
[1] For example, what if the sender types in `You should go to http://ww.example.com, where "example" must be replaced with your company name`? Suddenly `www.example.com` has an unintended DDoS!
> If the client is interpreting the content and then displaying its interpretation to the user, then it's not plain text anymore, is it?
Yes it is.
> It's a format
Yes, plain text is a format. The best format.
> in this case it's a poorly-specified, ad-hoc format and broken format[1] that is worse than simply having a reduced ad-hoc HTML format.
Well sure, plain text sucks at being HTML. That's because it isn't HTML; it's plain text. Plain text is not "poorly-specified, ad-hoc and broken" as plain text; only as HTML. The solution is not to use it as HTML.
> For example, what if the sender types in `You should go to http://ww.example.com, where "example" must be replaced with your company name`? Suddenly `www.example.com` has an unintended DDoS!
Ah, so that doesn't happen if the sender types in the wrong thing in HTML...?
>> For example, what if the sender types in `You should go to http://ww.example.com, where "example" must be replaced with your company name`? Suddenly `www.example.com` has an unintended DDoS!
> Ah, so that doesn't happen if the sender types in the wrong thing in HTML...?
I can't tell if you're being purposely contrarian or simply don't understand users.
The problem: Things that shouldn't be links get turned into links.
Your response: $SOME_OTHER_PROBLEM
I mean, really? You can't tell the difference between someone making a typo when intending to write a link and someone making a typo that results in a link?
So if you send that as text that isn't HTMLified by the recipient's client, they'll copy it as text and paste it into the adress line of the browser. The problem is still that the recipient goes to an adress the sender didn't intend (i.e. the recipient is stupid); has nothing to do with HTML vs text.
Or, if you want, the problem is that the recipient's client software HTMLifies text. Stupid client software (and possibly stupid recipient, for using the stupid software). Still has nothing to do with HTML vs text per se. Yes, that is literally $SOME_OTHER_PROBLEM. I mean, really? You can't tell the difference between various formats and problems caused by something else entirely?
(I get the feeling your supercilious "I mean, really?" was intended to slyly convey that I was the one being stupid here. IMO that backfired rather convincingly.)
Oh interesting, I pasted a URL in plain text and a bit of code in HN turned it into a link you can click on. I think it's totally fine for email clients to do that too.
The only thing I find redeeming about HTML email is the ability to have inline images so when I'm illustrating some sort of process to somebody I can do it more clearly. Without those, I'd create and send a proper document (I don't object to attachments), or publish the information on a wiki/blog/etc - but perhaps a those would be overall better approaches than a 'rich' email.
Hard disagree. Things like bolding text, adding pictures, changing colors, etc are very important for the emails I send. So some amount of HTML is important to me.
Lack of ability to distinguish between pre-formatted text and regular prose alone makes it a complete non-starter for most who aren't reading monospaced text in a terminal. I don't really like reading monospace text for prose (many people don't), and using proportional fonts means things that are supposed to be aligned will break (and if you restrict yourself to text only, you'll find yourself aligning things on occasion for tables or other content).
I actually use plain text in FastMail because it's "better" than HTML (usually), but it's not good.
Ability to send text/markdown natively would be pretty brilliant.
Ctrl-D to format the selected text as monospace in the Fastmail composer is pretty nice - I use it often for sending bits of log line or terminal output when writing up incidents or describing how to do something.
Gemtext[1] would have been perfect and way enough while still being legible on a terminal. Italic and bold can be done via unicode, you don't need a markup language for that.
This reads me as "I prefer letters" or "I prefer fax"
HTML is what non-techies want, or rather, they want to insert pictures and videos directly inline. They want to bold and highlight. They want bullet lists and numbered lists. They want to change fonts, make headlines, etc.. And they want it all to reflow for their device.
I do to. I don't want to say in the 70s terminal. I get that lots of techies wish the world was still 80 column monochrome ASCII only but you're the exception.
I think the "techies" that you are referring to just see the issues with html email that the non-techies don't notice. Some of course just want things to be more like the 80-column monochrome that you mention, but for most it's not that extreme.
I think HTML is way too complicated for email, and it would have been much better if they'd standardised on a version of markdown.
That ship has sailed though, so we're stuck between using HTML or plain text.
It's not like many spammers are using SPF and DKIM.
And then you have google sending bounce emails to spam although they already know with SPF that the original mail came from somewhere else making them the spammers.
Pretty much the only credit I'll give to Amazon is that they give the option to get plaintext emails. Doesn't mask the larger problems, but still a nice thing I wish was the norm.
That should be up to the recipient. Every other vendor provides this essential information in order confirmations.
Amazon's refusal to do so means you can't search your E-mail history for purchases (at tax time, for example). Or for warranty info or service. You may not know where you bought a particular item. Or which Amazon account you might have used.
If everyone followed Amazon's anti-customer example, you'd have to log into every E-commerce site you ever bought something from and search your order history... year by year... to find something. Unacceptable BS.
It's easy to say this, but can you imagine the hodge-podge of proprietary garbage we'd have to deal with if you couldn't email a simple file attachment to someone?
I'm good with attachment when you need to send me a real document, but if the email text itself ends up being multi-megabyte blob because you absolutely must have your name in the signature in blue and italic, then I tend to frown upon this. Over decades of my work I probably sent thousands of emails, yet very rarely if ever I needed HTML capabilities, and pretty much never ones that go beyond very basic Markup formatting.
Email attachments are defined through MIME and don't depend at all on HTML being available as a Content-Type. We could well have had another format and attachments together.
HTML is not needed for attachments to work. If the government for example, banned all use of HTML in emails, people could still attach (non-HTML) files to emails the same way they do now. Therefore the comment I replied to, a defense of HTML in emails, is a bogus argument.
> The point is that attachments are needed to make HTML work.
They are not.
MIME headers are helpful for telling MUAs what the content (type and/or disposition) of a message is, but there's nothing from stoping mail clients from just putting "raw" HTML in the body of an e-mail message without MIME.
A browser engine is necessary to render an HTML email, and browser engines have large attack surfaces -- and in general they are very complicated, which makes them difficult to reason about.
Also, normies don't write HTML, but rather they depend on services (like Gmail) offered by corporations to transform their composition into HTML, which gives the corporations and avenue to track me or to try to persuade or influence me unless I want to respond by instructing my normie friend never to send me email.
In general, HTML email brings the privacy and security problems of the web to email.
Also, HTML makes email much harder to archive because an HTML document's legibility often depends on references (embedded in the HTML document) to files on the internet, and these references to online files tend to rot.
Some of us are tired of web tech spreading its tentacles everywhere, especially to technologies like email that were already useful and mature before web tech started spreading to them.
I think that hodge podge (OneDrive, Google drive, Dropbox, etc) is what most people already use. "Simple file attachments" are an oxymoron these days--size/extension restrictions, spam scores, not to mention the hell of iterating over email.
Depends on your use case. Sometimes I want to send a document and not have the receiver change it at their whims. E.g. quotes for jobs. Simple attachments are great for that. Also I find some people who aren't good with tech find attachments much easier to deal with. If I send a an attachment I am 100% confident the other person can open it. No so for sharing links etc.
I would love for a middle-ground to emerge - plain-text emails with rudimentary formatting and ability to inline images. Something like markdown/asciidoc would be fine for overwhelming majority of cases. Unfortunately we ended up in a world where HTML email is a commonplace…
I was also a bit disappointed by the lack of open source coverage. If someone uses proprietary crap that doesn't work, they can go cry to their vendor, but I'd like Thunderbird, K9, FairEmail, and RoundCube to work for example. Anyone is free to use these so it would be cool if emails work there
Would you be interested in adding RoundCube, FairEmail, and K9 support? Those clients I'm familiar with so I can easily load up some eml files into my IMAP server and try them out, but it's some 144 tests total and a tad much to do all alone for "fun"
Outlook supporting padding in 2003 then not really supporting it in any follow up client sounds just about right for the dumpster fire experience that is trying to make an email look nice.
I wish there was something like BrowserStack but you send a test email and it shows you how it renders on tons of different email clients on various platforms. It wouldn't work for web-based email like Gmail but it would still be useful.
Litmus, testi@, Email on Acid, InboxMonster, SendForensics, Email Preview Services…
Most if not all also support stuff like deliverability, DMARC testing, Analytics, Accessibility, as well as web-based render testing. I think rendering engine wise, Testi@ has the largest device/platform coverage. Or at least last I checked.
https://caniuse.com/ is a popular tool to check what web features are working across different browsers - "can you use this and assume that it will work for others".
caniuse is an extremely popular website among people that had to touch web technologies, so much that almost anyone searching for issues on web apis seriously will have hard time not stumble upon it very quickly.
Hence, it's a totally valid assomption that the HN crowd might be aware of it. I'm sorry you were not, but you really are an outlier on this, which is really not a bad thing, btw.
Thanks for the reply, but I've read HN almost daily for years and have been a professional developer for way longer than that. I also just finished an API-definition project that involved a ton of research on API design and code-generation tooling (with OpenAPI in particular).
I have never heard of "caniuse." Swagger? Postman? Mocking tools and services? Lots of their ilk? Sure. In fact just recently I saw this API article posted here: https://news.ycombinator.com/item?id=40161794
caniuse.com is a website, where developers can check which features are supported by which browser and their versions. It is a immensely useful resource for webdevs.
Soooooo happy that my mail client is not even on the list here. It automatically strips out anything remotely looking like html and it sends out plain text emails only, as email was designed to be and should still be.
Anyone sending me css garbage will be directed to /dev/null. Thanks.
Reminds me of someone I knew 15 years ago, who often said "Anyone sending me text messages with abbreviations doesn't deserve a response". Sadly, now this guy has hardly any friends.
Have you ever come across the insanely rare use case of wanting to put something in italic or bold?
Or even more insane, maybe wanting to add a link in an email?
Or, you ever purchase anything online? It’s kind of nice to have line items in receipts and an image of the thing I bought. But then again, I’m an irrational human who enjoys things like “aesthetic readability.”
As a true purist, do you also exclusively program in Machine code? Because that’s how all software was originally designed to be.
We've tried building email templates for notifications for our apps where I work, and it has typically been a pain. We have since swapped to using mjml (https://mjml.io/) to build the templates, and it's working wonders. The output seems the be the most compatible with all different devices that we've tested on.
The other tool we enjoy using is Litmus (https://litmus.com), which allows you to throw in an email template and see what it looks like on all kinds of apps and devices. Other thread here mentions https://testi.at/ as well, which we've also had success with.
All of these have been really invaluable to designing emails for our apps.
I've been using Foundation for Emails[1] for the very small number of emails that I've worked on which required more than just a list of img tags, and I really appreciate it for existing because HTML emails have been stuck in ie6 web days.
[1]: https://get.foundation/emails.html
I hope the upcoming EU Accessibility Act will be enough for many organizations to finally make their emails accessible. I disable images by default in my email client, and some emails are pretty much empty without them, without providing any alternative.
Isn’t the whole point of sending emails to get the recipient to read them? If the recipient can’t read them, you wasted that money and captured no value. Possibly negative value because you just reminded the recipient of how annoying your website is. “Oh right, that vendor with the full-page modal that I couldn’t dismiss, or was it the vendor that had a pretty site that turned gray three seconds after loading for not discernible reason and wouldn’t let me click anything after that? I’ll just shop at Amazon next time even though they’re more expensive and vaguely evil.”
We have a html and txt template for each email we send. It's not exactly double the work, but it's appreciated by some of our customers.
In my experience one of the biggest causes of clipping is styled links with lots of tracking, oddly enough.
Using frameworks like mjml can add a lot of arbitrary markup that’ll rapidly increase the size of your email.
[1] https://react.email
So outlook today is the internet explorer of mail?
there is money to be made here.
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.
- 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.
HTML email would not be a thing if only adtech people used it, my man.
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.
There are two parts to how HTML email is used: Creation and consumption. The average person consumes HTML email.
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.
...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.
And parent said "you don't know enough people", not "you don't know any people".
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.
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.
https://lutrasecurity.com/en/articles/kobold-letters/
And if we have to chose between bold letters or less malware, we should choose the latter.
But the mail protocol is still the same.
Email is a standards backwater, but the solution is not to kneecap it.
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.
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
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.
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.
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.
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.
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.
Can I Email? - https://news.ycombinator.com/item?id=27112960 - May 2021 (273 comments)
Can I Email: ‘Can I Use’ for email - https://news.ycombinator.com/item?id=20948826 - Sept 2019 (196 comments)
'Can I Use' for Email - https://news.ycombinator.com/item?id=20934601 - Sept 2019 (1 comment)
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.
https://en.m.wikipedia.org/wiki/Usage_share_of_web_browsers
https://www.techinasia.com/chrome-firefox-chinese-online-ban...
It kind of does:
> popular - prevailing among the people generally --- https://www.dictionary.com/browse/popular
I didn't mean to say most preferred.
[1] https://www.w3.org/TR/epub-33/
I wouldn't want my email client to support arbitrary PDF features, either.
I get that adtech is interested in using my email as their billboard, but they can fuck right off. Plaintext + attachments or gtfo.
CanIEmail? The answer is generally no.
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
- <del> element
- <div> element
- <h1> to <h6> elements
- <hr> element
- <img> element
- <p> element
- <pre> element
- <span> element
- <strong> element
- <table> element
- valign attribute
- JPG image format
- PNG image format
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.
I think the whole mess could have been averted if Markdown had been invented about twenty years earlier.
1. <https://www.rfc-editor.org/rfc/rfc1896>
You're really rolling a dice on what may work, even if it's valid HTML
The real issue is bespoke rendering engines instead of just using a rule of "everything the current browser can do, but no js".
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 <div style="position:fixed"> in emails crazy? Yes. Do you need to deal with it? Also yes.
Mandate markdown and MTAs and marketing departments will send you markdown only made of pure HTML.
``` #include <stdio.h>
int main() { /* my software in ASM */ __asm__ ( [...<insert your assembly code lines here>...] );
} ```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.
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.
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.
That’s when I learned gmail doesn’t support SVG???? That seems like a huge miss.
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.
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.
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.
When I enter "<a href="https://example.org>Test</a>" it says "No results found. Why not suggest this feature to be added?".
When I enter "<a>" 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?
https://www.caniemail.com/search/?s=marquee
And emails can totally be sent both as plaintext and HTML, so that the receiver can choose! I just don't understand why so many services only send a text/html version instead of both text/html and text/plain.
It's been A DECADE NOW
https://stackoverflow.com/questions/15136480/how-to-send-htm...
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.
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.
But at this point, it's pretty clear that most non-technical people prefer emails with fancy text and graphics.
Personally, I'm just glad that email is a flexible enough medium to allow that. It's better than the alternative, where people moved to some closed, proprietary protocol behind like 20 patents that allows the same thing.
Is there any other common way we communicate over screens (aside from http) that has had the staying power of email for the general public? I think that's a testament to the sheer flexibility of it. The ugliness that people have contorted email into is a badge of honor IMO
And what percentage of e-mails from people / human beings have those things?
Certainly marketing e-mails have fancy formats, but I've rarely seen any person at a companies I've worked at use any kind of formatting: generally most folks hit reply and start typing with whatever the default is. Hardly any italics or bold, and forget about fixed width (for things like CLI commands in technical discussions).
Heck, even Slack messages these styles are hardly used (on my current team I use them the most since I know that Markdown so it's easy for me to throw in some **, //, or `` in my typing flow, so I can highlight hostnames, CLI commands, etc).
I also generally prefer structured formatting to plain text.
If you're sending emails with thousands of words you have probably chosen the wrong medium.
I am not.
I don't receive e-mails with fancy formatting at all. As for hyperlinks: I can paste a URL just fine without an <A HREF…> tag.
(I'll take this report as a "we need to make it clearer you can do this!")
Anecdotally, I only get 2-3 actual human emails per _year_. Rest is transactional spam.
I understand if you are manager/owner you might be running comms via email. But internally all of that went to slack for good reason - lack of history is a feature, not a bug.
I am neither manager nor owner. Just another 1x engineer. 75% of my comms run over email. 25% over Jabber.
Not every software company uses Slack!
Email is good for having common interface. In my case it's ~abused in 99% of cases.
Also - you do not mention how much non-comms emails do you receive. While chat apps are fucky in terms of lock-in, lack of interop and tons of other things, lack of spam is nice.
Your first statement might be true (it's debatable). Your second is definitely false.
Lets assume that HTML really was the worst thing that ever happened to email. Plain text content for email is still not the best content.
People want to:
1. Click on a link in the email, not fumble with copy and paste on their phone.
2. See decently formatted paragraphs and content with bold, italics and different font sizes for headings and paragraphs, not a wall of text.
3. See images in the email itself, not have to once again fumble around with copy and paste.
4. Correctly formatted bullet points, including sub-lists.
For all of the above, some sort of format is required. If we exclude HTML as a possibility, you're still going to have to need a format of some type, because the wall-o-text format is not a good UI.
The most contagious/problematic issue is (3) and inlining - as I said, it's possible to attach anything but the location is lost. Probably something simple like anchor (again, markdown linking comes to mind) to indicate placement would be just fine...
(I loath html mails with passion…)
I think this comment displays the problems with plain text. I really couldn't have provided a better example.
As regards the counterpoints:
1. All links are clickable
Yes, and that's a bug. "http://www.example.com" should not be a clickable line. More to the point, it's not plain text anymore if the user gets something that has been interpreted and then rendered by the software.
2. It's not obvious how this should be done, and how it should reflow. You yourself failed to manage this in your reply, which I consider a good argument for why plain text is a poor UI.
3. Who cares whether you need it or not. The reality is that the clear majority of people use it!
4. Once again, if we're talking about a specific format that gets rendered into something readable, then it's not plain text anymore.
I'm arguing against the GPs assertion that plain text is the best format, not that markdown is insufficient.
Arguably it is. It was sent as plain text and received as plain text. The fact that the recipient's software goes through and interprets that plain text and does something when it detects an URL in it doesn't change that. If the recipient were to use some other software that doesn't do that, they'd see... Plain text. Because that's what it is.
Exactly like .... the subset of HTML we see in emails?
I have not yet gotten an HTML email that, when displayed in plain-text, was unreadable. Neither, I suspect, have you.
I'm glad that you never ever received any link to some derivation of st.es.rui.tracking/bzzz/pfrrrrt?campaign=hn that hide the real link, but in the real world, that's how tracking is done. Plain text doesn't prevent anything.
> not sure if needed, besides you can attach images to plain text (though not inlining) or click-able links to external sources (at exact place)
For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.
You want to argue that plain text is better, but your arguments are that plain tex, are better for you. Don't make the mistake to assume that your specific experience is a workable average.
Sadly many people on HN do exactly this, as seen in comments like
"I don't use a phone and don't have a phone number, so I can't pass the anti-spam check of xx website. It is their fault"
"Why do we need a UI for this? Command line is much better than this"
"Why do we need to do this? I have been installing applications by compiling from source since 199x and it has worked perfectly fine for me."
PS. I assume all your github readme.md are all in full-blown HTML sprinkled with tracking links? :P
That's the thing - I do get lots of them. In the age of html+plain and abuse of tracking (because it's so easy to hide with html), plain text version is just littered with this nonsense...
For example I just got notification from allegro.pl (shopping platform) and all links have that:
`?utm_source=notification&utm_medium=cartWithPayment&utm_campaign=cef…35-c856-…-…-687c…cdd6&tr_n=buyer-cart&tr_id=f09…d40-…-…-…-05b0…7126-…__f09d2e80-…-…-…-05b0ee617126-…&tr_d=allegro.pl&tr_c=purchase-details&tr_s=LM…sCz>`
As for attachments - obvious exaggeration to dismiss actual issue: bravo…
> You want to argue that plain text is better, but your arguments are that plain tex, are better for you. Don't make the mistake to assume that your specific experience is a workable average.
Don't assume that someone using HTML actually do it conciously or is glad to receive it in that form because average user doesn't complain about it
> As for attachments - obvious exaggeration to dismiss actual issue: bravo…
No, the issue is that you can't tell everyone to "just upload the picture somewhere and put the link in the middle", that's unreasonable. That is the issue. HTML solves an issue.
> Don't assume that someone using HTML actually do it conciously or is glad to receive it in that form because average user doesn't complain about it
Average users want formatting. Plain text doesn't provide it. HTML for emails sucks, but plain text isn't a solution to that.
If only. Everyone I know who isn't an IT professional -- and many who are, too! -- sends links like https://www.example.com/something/somepage/?tracker=ASfas142......
If the client is interpreting the content and then displaying its interpretation to the user, then it's not plain text anymore, is it? It's a format; in this case it's a poorly-specified, ad-hoc format and broken format[1] that is worse than simply having a reduced ad-hoc HTML format.
Just like HTML is "plain text" which is interpreted by the client and that interpretation is displayed to the user.
[1] For example, what if the sender types in `You should go to http://ww.example.com, where "example" must be replaced with your company name`? Suddenly `www.example.com` has an unintended DDoS!
Yes it is.
> It's a format
Yes, plain text is a format. The best format.
> in this case it's a poorly-specified, ad-hoc format and broken format[1] that is worse than simply having a reduced ad-hoc HTML format.
Well sure, plain text sucks at being HTML. That's because it isn't HTML; it's plain text. Plain text is not "poorly-specified, ad-hoc and broken" as plain text; only as HTML. The solution is not to use it as HTML.
> For example, what if the sender types in `You should go to http://ww.example.com, where "example" must be replaced with your company name`? Suddenly `www.example.com` has an unintended DDoS!
Ah, so that doesn't happen if the sender types in the wrong thing in HTML...?
> Ah, so that doesn't happen if the sender types in the wrong thing in HTML...?
I can't tell if you're being purposely contrarian or simply don't understand users.
The problem: Things that shouldn't be links get turned into links.
Your response: $SOME_OTHER_PROBLEM
I mean, really? You can't tell the difference between someone making a typo when intending to write a link and someone making a typo that results in a link?
Or, if you want, the problem is that the recipient's client software HTMLifies text. Stupid client software (and possibly stupid recipient, for using the stupid software). Still has nothing to do with HTML vs text per se. Yes, that is literally $SOME_OTHER_PROBLEM. I mean, really? You can't tell the difference between various formats and problems caused by something else entirely?
(I get the feeling your supercilious "I mean, really?" was intended to slyly convey that I was the one being stupid here. IMO that backfired rather convincingly.)
Oh interesting, I pasted a URL in plain text and a bit of code in HN turned it into a link you can click on. I think it's totally fine for email clients to do that too.
The only thing I find redeeming about HTML email is the ability to have inline images so when I'm illustrating some sort of process to somebody I can do it more clearly. Without those, I'd create and send a proper document (I don't object to attachments), or publish the information on a wiki/blog/etc - but perhaps a those would be overall better approaches than a 'rich' email.
Hard disagree. Things like bolding text, adding pictures, changing colors, etc are very important for the emails I send. So some amount of HTML is important to me.
I actually use plain text in FastMail because it's "better" than HTML (usually), but it's not good.
Ability to send text/markdown natively would be pretty brilliant.
[1] https://geminiprotocol.net/docs/gemtext.gmi
HTML is what non-techies want, or rather, they want to insert pictures and videos directly inline. They want to bold and highlight. They want bullet lists and numbered lists. They want to change fonts, make headlines, etc.. And they want it all to reflow for their device.
I do to. I don't want to say in the 70s terminal. I get that lots of techies wish the world was still 80 column monochrome ASCII only but you're the exception.
I think HTML is way too complicated for email, and it would have been much better if they'd standardised on a version of markdown.
That ship has sailed though, so we're stuck between using HTML or plain text.
Mmm... Paradise
Mind-bogglingly stupid and annoying.
Amazon's refusal to do so means you can't search your E-mail history for purchases (at tax time, for example). Or for warranty info or service. You may not know where you bought a particular item. Or which Amazon account you might have used.
If everyone followed Amazon's anti-customer example, you'd have to log into every E-commerce site you ever bought something from and search your order history... year by year... to find something. Unacceptable BS.
Also lack of a signature section, relying on weird -- \n hacks
They are not.
MIME headers are helpful for telling MUAs what the content (type and/or disposition) of a message is, but there's nothing from stoping mail clients from just putting "raw" HTML in the body of an e-mail message without MIME.
Why not HTML? At least it isn't RTF or some wonky SGML evolutionary dead-end.
Also, normies don't write HTML, but rather they depend on services (like Gmail) offered by corporations to transform their composition into HTML, which gives the corporations and avenue to track me or to try to persuade or influence me unless I want to respond by instructing my normie friend never to send me email.
In general, HTML email brings the privacy and security problems of the web to email.
Also, HTML makes email much harder to archive because an HTML document's legibility often depends on references (embedded in the HTML document) to files on the internet, and these references to online files tend to rot.
Some of us are tired of web tech spreading its tentacles everywhere, especially to technologies like email that were already useful and mature before web tech started spreading to them.
> Gmail (Android) : 111/284
Interesting corrective to the “Apple is holding back HTML” narrative that appears so often on HN.
Would you be interested in adding RoundCube, FairEmail, and K9 support? Those clients I'm familiar with so I can easily load up some eml files into my IMAP server and try them out, but it's some 144 tests total and a tad much to do all alone for "fun"
> For privacy reasons, the styles that can be modified using this selector are very limited
* Disclaimer: Not affiliated, just a happy customer.
- [1] https://testi.at/
Most if not all also support stuff like deliverability, DMARC testing, Analytics, Accessibility, as well as web-based render testing. I think rendering engine wise, Testi@ has the largest device/platform coverage. Or at least last I checked.
As a rule of thumb (well, wishful thinking, I realize), if Wikipedia doesn't know it, spend a few words to introduce a term.
Hence, it's a totally valid assomption that the HN crowd might be aware of it. I'm sorry you were not, but you really are an outlier on this, which is really not a bad thing, btw.
I have never heard of "caniuse." Swagger? Postman? Mocking tools and services? Lots of their ilk? Sure. In fact just recently I saw this API article posted here: https://news.ycombinator.com/item?id=40161794
At first I thought it was some kind of service for dog owners, until I noticed the missing N. So... that left no explanation.
Anyone sending me css garbage will be directed to /dev/null. Thanks.
(Some email clients for humans probably add a bit of html and css to everything, but you get what I mean. It still looks like plain text)
Or even more insane, maybe wanting to add a link in an email?
Or, you ever purchase anything online? It’s kind of nice to have line items in receipts and an image of the thing I bought. But then again, I’m an irrational human who enjoys things like “aesthetic readability.”
As a true purist, do you also exclusively program in Machine code? Because that’s how all software was originally designed to be.
Seems silly to get religious about it.