Can I Email?(caniemail.com)
caniemail.com
Can I Email?
https://www.caniemail.com/
289 comments
Curious, what's the risk with SVG, assuming a CSP is used for it that doesn't allow anything (including no scripts)?
SVG is a minefield so massive it's hard to give an exhaustive list of everything that could go wrong. Especially when these kinds of assets might be hosted on user content domains and where webmail clients might allow access to the SVG content with inline disposition but outside of an IMG tag (most browsers enable/disable various SVG features such as JS or an app cache manifest according to context). There are also a ton of weird rendering modes that can be triggered for SVG (or MathML) and these can be used to bypass XSS sanitizers by means of mXSS which exploits differences in browser renderings when roundtripping content.
And sites with strong CSPs are often especially vulnerable to scriptless attacks, perhaps because they feel more protected. For example, in 2019, there was a bug bounty disclosure to Fastmail about a way to intercept and proxy all email attachment downloads, completely client-side, and yet without involving any JavaScript, simply using HTML5 AppCache. This also affected a whole lot of other providers, but the Fastmail team patched this within 24 hours, a pretty amazing response, and the quickest by far.
Here's a fantastic paper from Mario Heiderich (of Cure53) from 2012 on various kinds of scriptless attacks: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.46...
And sites with strong CSPs are often especially vulnerable to scriptless attacks, perhaps because they feel more protected. For example, in 2019, there was a bug bounty disclosure to Fastmail about a way to intercept and proxy all email attachment downloads, completely client-side, and yet without involving any JavaScript, simply using HTML5 AppCache. This also affected a whole lot of other providers, but the Fastmail team patched this within 24 hours, a pretty amazing response, and the quickest by far.
Here's a fantastic paper from Mario Heiderich (of Cure53) from 2012 on various kinds of scriptless attacks: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.46...
I've said it before, I'll say it again: the web needed a vector answer to jpeg, but what we got was a vector answer to html+css with all their commensurate vulnerabilities and complexities.
The other major web vector format...
is PDF. Yeah, PDF has drawing commands. Most vector formats are based on command sequences, that map 1-1 with what you'd find in a drawing library like Cairo. EPS and PDF both work that way, which makes it even more of a typical vector format than SVG (which only does the command sequence thing with paths, AFAIK). Of course, it's not that well supported (the in-browser reader does who-knows-what to get it to render, I think it's converted to DOM elements), but it is the other major browser-supported vector format.
is PDF. Yeah, PDF has drawing commands. Most vector formats are based on command sequences, that map 1-1 with what you'd find in a drawing library like Cairo. EPS and PDF both work that way, which makes it even more of a typical vector format than SVG (which only does the command sequence thing with paths, AFAIK). Of course, it's not that well supported (the in-browser reader does who-knows-what to get it to render, I think it's converted to DOM elements), but it is the other major browser-supported vector format.
I’d love to know where FastMail ranks on here.
Fastmail's security is top notch. They're using Cure53's DOMPurify and their team understand these vectors really well, with strict filtering. Their pixel tracking blocking was better than Hey's when last I checked, and I reported three leaks to Hey that were not fixed for some time. Fastmail also run one of the best bounties I have ever participated in. I would even say significantly better than ProtonMail, having participated in both bug bounties.
Nice to hear that, I'm a Fastmail customer and the Android up is subpar on offline access (or unreliable connections, looks like it's basically hitting the network for everything. Knowing that at least security-wise it's a good product makes me happier.
What are the advantages of using FastMail's android app over a normal mail client? I'm thinking of moving to Fastmail from Gmail.
Some more integration with other FastMail services (like calendar or "disk space" for files) mainly. Also normal MUAs on Android are usually ugly as hell, I still have to find one that I really like. But the online-only bug of FM client is really becoming an issue worth switching.
shrug dunno what other mail clients have but I've used Fastmail's email client for over a decade and never thought "wonder if someone else's is better".
This makes me happy I chose it
Oh yeah.
Those nth-child* selectors Gmail strips out are a real security nightmare.
Those nth-child* selectors Gmail strips out are a real security nightmare.
defaultname(1)
>This page ranks email clients based on their support among the 182 HTML and CSS features
No thanks. I still recoil at the sight of a read-receipt and the only reason most companies include any of this dreck in an email in 2021 is to either track me or market to me.
make email text again.
No thanks. I still recoil at the sight of a read-receipt and the only reason most companies include any of this dreck in an email in 2021 is to either track me or market to me.
make email text again.
> make email text again
That ship sailed the instant it got named "email" instead of something like "etelegram".
With mail, I can send anything that my printer can print, which is everything my word processor can handle (fonts, text decoration, foreground and background colors, inline images, graphs, tables, and more) and attach anything that fits in the envelope (a CD-ROM of arbitrary data in any format).
It was inevitable that email would end up being able to handle the electronic equivalent of all those things.
The problem with email is not that it now handles more than just plain text. The problem is that there was no early agreement on how to handle those things, so different implementors came up with different ways to do it, which eventually converged on using HTML. Not because HTML was necessarily the best way to do it, but because it was something they all already implemented for other things or was already available on the systems their mail clients ran on.
But modern HTML engines are designed for the web, so there still really needs to be some sort of agreement on a subset of HTML that handles the things necessary to make email like mail, without including things that make sense for the web but not for mail.
That ship sailed the instant it got named "email" instead of something like "etelegram".
With mail, I can send anything that my printer can print, which is everything my word processor can handle (fonts, text decoration, foreground and background colors, inline images, graphs, tables, and more) and attach anything that fits in the envelope (a CD-ROM of arbitrary data in any format).
It was inevitable that email would end up being able to handle the electronic equivalent of all those things.
The problem with email is not that it now handles more than just plain text. The problem is that there was no early agreement on how to handle those things, so different implementors came up with different ways to do it, which eventually converged on using HTML. Not because HTML was necessarily the best way to do it, but because it was something they all already implemented for other things or was already available on the systems their mail clients ran on.
But modern HTML engines are designed for the web, so there still really needs to be some sort of agreement on a subset of HTML that handles the things necessary to make email like mail, without including things that make sense for the web but not for mail.
I don't think naming it "etelegram" would have changed anything. It's just a name.
>But modern HTML engines are designed for the web, so there still really needs to be some sort of agreement on a subset of HTML that handles the things necessary to make email like mail, without including things that make sense for the web but not for mail.
What would you think only makes sense for the web and not for mail?
What would you think only makes sense for the web and not for mail?
No one knows if I opened a letter or threw it in a trash can.
But if it was sent registered they can at least know that you received it. And from what I gather, the consensus of most jurisprudence is that given you received it, throwing it away unopened is on you.
So if someone wants a “read receipt” they should pay, and the recipient should have the right to receive or not.
That should work to each party’s satisfaction.
That should work to each party’s satisfaction.
registered return receipt signature required - maybe you can prove who received it.
Just sending something registered won't help your jurisprudence :p
Just sending something registered won't help your jurisprudence :p
In the US it does - if you send something registered mail, so long as it's delivered, it's on the recipient whether or not they read it
Likewise, if it's refused, it's on the recipient to be responsible for whatever they didn't accept
Likewise, if it's refused, it's on the recipient to be responsible for whatever they didn't accept
If companies want to have inline images in their emails, they should have to send the image data along with the rest of the message. Email clients should not allow emails to load third party resources.
What, so that the client has literally no choice of not showing the images, even you just want to view the text version?
Good email clients already provide a very simple solution: a user option to disable loading remote content, with a per-message option to load it.
Your suggestion would mean that my mail client has to download a ridiculously larger volume of data than it does now.
Good email clients already provide a very simple solution: a user option to disable loading remote content, with a per-message option to load it.
Your suggestion would mean that my mail client has to download a ridiculously larger volume of data than it does now.
You can track people through CSS?
Specify a background image?
Was a genuine question
I intended it as a genuine answer. Sorry if it appeared a bit snarky.
To expand a bit: With css, you can specify a background image to any document element. Something like this, where the url serves to identify you:
To expand a bit: With css, you can specify a background image to any document element. Something like this, where the url serves to identify you:
div.foo {
background-image: url('https://example.com/bar.png?t=deadbeef')
}
Load a background image and store the IPs that asked for it.
"Outlook (Windows)" is dead last in the "rankings". That's pretty much the only page on there that matters sadly; Determining which features work on Outlook for Windows and that's the maximum that can go into an HTML EMail.
Sure, I'd love to only send txt mails but that sadly does not align with the expectations/desires of the companies I've worked with.
Sure, I'd love to only send txt mails but that sadly does not align with the expectations/desires of the companies I've worked with.
If Microsoft could just bundle their Edge/Chromium renderer instead of their ancient WordHTML engine, or even the EdgeHTML engine of the previous Edge, they'd do the whole industry a huge favor. It's so frustrating their holding us back. Instead, they allow Google to push technologies like AMP for email for things that could probably be solved with standard HTML.
The situation is wild. In older Outlook versions they've used IE to render the received mails but used a custom engine when you were writing/editing an email. You could even use Word as an editor so you could generate the HTML using Word as your WYSIWYG IDE. I can understand why that needed some consolidation into one editor and one engine but re-using Word so they wouldn't have to create a new editor wasn't the best decision for the ecosystem.
WYSIWYG editors and rendering engines aren't things I know about so I wonder if there have been difficult engineering issues at that time or if they just went at it from a business standpoint of "people see mail like letters so they are documents for which we have word so let's use that".
//Edit: Looks like they were mainly interested in providing a great WYSIWYG experience using tools users are already familiar with: https://web.archive.org/web/20110311083708/http:/blogs.offic... great quote: "There is no widely-recognized consensus in the industry about what subset of HTML is appropriate for use in e-mail for interoperability. The “Email Standards Project” does not represent a sanctioned standard or an industry consensus in this area. Should such a consensus arise, we will of course work with other e-mail vendors to provide rich support in our products." - I guess their argument could be that there still is no "HTML standard for email" so they don't have to support anything they don't want to?
WYSIWYG editors and rendering engines aren't things I know about so I wonder if there have been difficult engineering issues at that time or if they just went at it from a business standpoint of "people see mail like letters so they are documents for which we have word so let's use that".
//Edit: Looks like they were mainly interested in providing a great WYSIWYG experience using tools users are already familiar with: https://web.archive.org/web/20110311083708/http:/blogs.offic... great quote: "There is no widely-recognized consensus in the industry about what subset of HTML is appropriate for use in e-mail for interoperability. The “Email Standards Project” does not represent a sanctioned standard or an industry consensus in this area. Should such a consensus arise, we will of course work with other e-mail vendors to provide rich support in our products." - I guess their argument could be that there still is no "HTML standard for email" so they don't have to support anything they don't want to?
They could easily do that. But they want to use their Word component to compose replies to emails. So it needs to go through the WordHTML at some point..
And from that perspective, it's better to break the mail as it's coming in (so the sender gets blamed) rather than at the moment the user clicks reply.
And from that perspective, it's better to break the mail as it's coming in (so the sender gets blamed) rather than at the moment the user clicks reply.
Biggest joke is, they're already having a decent renderer on macOS.
You can load plain HTML as a .eml template into it and send it off... but not on Windows, you're stuck with some weird undocumented binary format there.
You can load plain HTML as a .eml template into it and send it off... but not on Windows, you're stuck with some weird undocumented binary format there.
I will never believe or respect Microsoft's supposed "open source" renaissance until they do something about reading and writing proper HTML/CSS in Outlook-Windows. The damage from the last 15 years of WordHTML has been irreversible.
There is nothing I hate more than rich content email.
Send me plain text email.
Add attachments that I can scan for issues before I open them.
If you send me links, I will be very wary of visiting them outside a sandboxed tab. I will not 'click through' from the email client.
Send me plain text email.
Add attachments that I can scan for issues before I open them.
If you send me links, I will be very wary of visiting them outside a sandboxed tab. I will not 'click through' from the email client.
I like to use wheregoes.com to probe links. I'm surprised at how many redirects some of them have. I get that an ad link might go through an ad channel, but clicking one non-spam link from a reputable company can plant cookies from a whole bunch of websites.
> If you send me links, I will be very wary of visiting them outside a sandboxed tab.
I got a link to re-up a certain type of account from my bank. It was very odd, I was quite confused.
I got a link to re-up a certain type of account from my bank. It was very odd, I was quite confused.
As a side note, I'm amazed that it's 2021 and there's no good mainstream email framework. Foundation ain't it, and MJML is a straight up non-option.
Not a framework but I’ve found Ted Goas’ Cerberus templates very useful.
I customized them, extracted them into modules and created a design system which I then translated to an email CMS.
Coverage is pretty good although Outlook still glitches in some circumstances.
https://tedgoas.github.io/Cerberus/
FWIW caniemail is unreliable and does not have full coverage.
Also with this level of complexity I’d rather start with a few tested patterns than navigate the insane labyrinth of email client inconsistencies.
I customized them, extracted them into modules and created a design system which I then translated to an email CMS.
Coverage is pretty good although Outlook still glitches in some circumstances.
https://tedgoas.github.io/Cerberus/
FWIW caniemail is unreliable and does not have full coverage.
Also with this level of complexity I’d rather start with a few tested patterns than navigate the insane labyrinth of email client inconsistencies.
Yep, I think we need more tools like this around.
Why is MJML a non-option? It was a huge time saver for me. Combine it with react-mjml and you can get typesafe email templates that work in pretty much any browser. I managed templates by hand for a long time, and it took me a couple weeks to replace everything with MJML, but it was worth it.
I'm remaking my workplace's transactional emails these days (order confirmation, receipt etc. for an online shop - emails customers also reply to when stuff doesn't go as expected). We want something responsive for smartphones, but are primarily a B2B company.
I made what they wanted with MJML. Looked good in a browser, gmail and phone.
Outlook had a few issues, can't remember which right now.
But replying from Outlook simply broke the styling completely. Gaps between each section, complete mess. Not the impression you want to give the customers when their order goes wrong. B2B means Outlook is what out customers use.
I've found that replying via Outlook is the ultimate integrity test of an eamil.
Now I'm making them by hand and it is a madening cargo cult bonanza. Takes a lot of time.
I guess MJML is fine for marketing.
I made what they wanted with MJML. Looked good in a browser, gmail and phone.
Outlook had a few issues, can't remember which right now.
But replying from Outlook simply broke the styling completely. Gaps between each section, complete mess. Not the impression you want to give the customers when their order goes wrong. B2B means Outlook is what out customers use.
I've found that replying via Outlook is the ultimate integrity test of an eamil.
Now I'm making them by hand and it is a madening cargo cult bonanza. Takes a lot of time.
I guess MJML is fine for marketing.
> But replying from Outlook simply broke the styling completely
This is an Outlook problem, not an MJML or even an HTML problem.
If you inspect the HTML for the email sent vs what Outlook sends on a reply you’ll see it has changed the code.
Here’s an excellent highlight of this bug https://www.hteumeuleu.com/2016/super-mail-forward-an-email-...
This is an Outlook problem, not an MJML or even an HTML problem.
If you inspect the HTML for the email sent vs what Outlook sends on a reply you’ll see it has changed the code.
Here’s an excellent highlight of this bug https://www.hteumeuleu.com/2016/super-mail-forward-an-email-...
> This is an Outlook problem, not an MJML or even an HTML problem.
Though you are technically correct, I just don't think this is a constructive attitude. Half the job of making emails is working around (Outlook) bugs. This is just the annoying world email coding.
If MJML is content ignoring Outlook bugs, MJML just isn't a satisfying tool for email makers.
Sure, it'll get the job done for some marketing, but now the developer isn't learning skills that will make robust emails beyond that.
Making robust emails becomes a completely separate skillset and the developer who chose to invest time in MJML will have to start all over learninging the necessary skills if he needs to make email you can actually reply to.
Though you are technically correct, I just don't think this is a constructive attitude. Half the job of making emails is working around (Outlook) bugs. This is just the annoying world email coding.
If MJML is content ignoring Outlook bugs, MJML just isn't a satisfying tool for email makers.
Sure, it'll get the job done for some marketing, but now the developer isn't learning skills that will make robust emails beyond that.
Making robust emails becomes a completely separate skillset and the developer who chose to invest time in MJML will have to start all over learninging the necessary skills if he needs to make email you can actually reply to.
> Though you are technically correct, I just don't think this is a constructive attitude.
I’ve worked in email for a decade, you do what you can with the tools you've been given. An email will never look perfect everywhere and while I agree with the general sentiment you’re talking about regarding folks learning proper email code rather than relying on tools, I also think the quality of emails sent is substantially higher now thanks to those tools.
I’ve worked in email for a decade, you do what you can with the tools you've been given. An email will never look perfect everywhere and while I agree with the general sentiment you’re talking about regarding folks learning proper email code rather than relying on tools, I also think the quality of emails sent is substantially higher now thanks to those tools.
The end user doesn't know that, and doesn't care.
Your boss is not your end user. The way your boss interacts with the emails you send is not the way your end users do. Optimising for your boss is not how this channel should work, though I appreciate there are a lot of bosses out there who don’t understand this.
I don't understand your point.
Are you complaining that his boss is forcing him to implement something that his end users can use?
If so, why isn't his boss right?
Personally, I'd say that yeah, he's supposed to work for his end user, why would he do anything else?
Are you complaining that his boss is forcing him to implement something that his end users can use?
If so, why isn't his boss right?
Personally, I'd say that yeah, he's supposed to work for his end user, why would he do anything else?
My point is that, from the perspective of email, you frequently receive internal feedback that doesn't correspond to how users actually use email.
For example, if the org uses desktop Outlook but < 1% of your audience does, is it worth optimising the email for that audience based on internal feedback?
If someone notices that something weird happens when an email is replied to or forwarded, is that something worth acting on based on the real world frequency of that action?
For example, if the org uses desktop Outlook but < 1% of your audience does, is it worth optimising the email for that audience based on internal feedback?
If someone notices that something weird happens when an email is replied to or forwarded, is that something worth acting on based on the real world frequency of that action?
[deleted]
I agree, I’ve had pretty good results using MJML now for several years (and I’ve been doing HTML emails since almost the 90’s!)
This is a problem area where a good abstraction framework is highly useful in my opinion.
That said I don’t specialise in email, it’s something I do “when I need to”. So if I was spending more time doing this sort thing, I might be more inclined to move down an abstraction level back to HTML/CSS and improve my knowledge of various client support.
To just get the job done though, MJML is highly recommended.
I see also a lot of mentions on this thread about replying to emails breaking the layout. Part of me thinks we’re fighting a losing battle here anyway so there is a limit to how much time it’s worth spending to make sure even replies are formatted nicely across all clients. But the other thing to consider is whether the email template is just trying to do too much.
I try and keep my email templates very sparse, clean and simple and I generally haven’t had too many issues with reply/forward formatting (that I’m aware of).
This is a problem area where a good abstraction framework is highly useful in my opinion.
That said I don’t specialise in email, it’s something I do “when I need to”. So if I was spending more time doing this sort thing, I might be more inclined to move down an abstraction level back to HTML/CSS and improve my knowledge of various client support.
To just get the job done though, MJML is highly recommended.
I see also a lot of mentions on this thread about replying to emails breaking the layout. Part of me thinks we’re fighting a losing battle here anyway so there is a limit to how much time it’s worth spending to make sure even replies are formatted nicely across all clients. But the other thing to consider is whether the email template is just trying to do too much.
I try and keep my email templates very sparse, clean and simple and I generally haven’t had too many issues with reply/forward formatting (that I’m aware of).
What’s wrong with MJML?
I don’t want a framework to lie to me about what it is that I’m writing.
I’m not interested in learning MJML. I’m interested in learning what subset of HTML and CSS email clients render and rasterize to.
That’s it.
I’m sick of stupid developers shilling their software product that I’m suppose to build other products with.
They do it with these cutesy photoshop/illustrator logos and dribbble crafted color schemes and drop in things like made with love in (city) in their README.mds on GitHub.
I want tools, not someone’s amateur marketing campaign.
I’m not interested in learning MJML. I’m interested in learning what subset of HTML and CSS email clients render and rasterize to.
That’s it.
I’m sick of stupid developers shilling their software product that I’m suppose to build other products with.
They do it with these cutesy photoshop/illustrator logos and dribbble crafted color schemes and drop in things like made with love in (city) in their README.mds on GitHub.
I want tools, not someone’s amateur marketing campaign.
"I’m interested in learning what subset of HTML and CSS email clients render and rasterize to."
Doesn't sound like you want a framework. Sounds like you want a book.
Doesn't sound like you want a framework. Sounds like you want a book.
Nope, plenty of CSS frameworks out there that don't try and make up their own tags.
The thing about email is that renderers aren't even implementing the same spec. There is no common subset to learn. Every client implements some vague mess of 1997-era HTML/CSS mixed with different random modern features. Any attempt to try to write anything slightly advanced manually will drive you insane. Mail clients will mangle your code in ways you can't imagine. Every client will mangle it slightly differently. Even the same client on different operating systems will behave differently.
Tools like MJML take a compiler approach to email. Why waste time trying to figure out how to implement a for loop in machine code and keep it updated every time a new processor comes out when you can just let the compiler do it?
Tools like MJML take a compiler approach to email. Why waste time trying to figure out how to implement a for loop in machine code and keep it updated every time a new processor comes out when you can just let the compiler do it?
Take the top email clients and you'll sure as hell find a common subset. I don't want something slightly advanced. Emails are text and images. That it's. There's nothing advanced about that, and I'm not looking for it, either.
The idea we need compilers for everything is idiot engineering.
The idea we need compilers for everything is idiot engineering.
The very site this thread is about addresses exactly this. The tl;dr is look at what is supported by Outlook.
If you just want text and images, you don't need CSS. Just the <img> tag - and even there you'll run into differences if you try and use the alt attribute.
And even that isn't trivial. For example, say you include an basic black on white icon, what happens if the user is using dark mode? If the image is transparent, it becomes entirely invisible. If it's non-transparent then it's ugly (white box). If you want to make it change depending on dark or light mode, now you have to use responsive CSS which works entirely differently in different mail clients. What happens if the image is bigger than their viewport? Hint: it is different in different clients.
And speaking of mail clients: one of the most popular mail clients is Outlook, which on Windows uses the Microsoft Word(!) HTML renderer and on Mac it uses WebKit. Gmail on web has its own HTML parser that outputs different HTML to what you wrote (and mangles your CSS class names). Apple Mail is probably the easiest to deal with.
It's not worth learning this stuff if you don't have to. It will not benefit your life in any way. The common subset you want is text/plain.
And even that isn't trivial. For example, say you include an basic black on white icon, what happens if the user is using dark mode? If the image is transparent, it becomes entirely invisible. If it's non-transparent then it's ugly (white box). If you want to make it change depending on dark or light mode, now you have to use responsive CSS which works entirely differently in different mail clients. What happens if the image is bigger than their viewport? Hint: it is different in different clients.
And speaking of mail clients: one of the most popular mail clients is Outlook, which on Windows uses the Microsoft Word(!) HTML renderer and on Mac it uses WebKit. Gmail on web has its own HTML parser that outputs different HTML to what you wrote (and mangles your CSS class names). Apple Mail is probably the easiest to deal with.
It's not worth learning this stuff if you don't have to. It will not benefit your life in any way. The common subset you want is text/plain.
MJML is abstracted from Mailjet’s email builder. It’s based on real-world HTML needs and the stuff it renders is pretty easy to read. You’ll end up re-implementing something like it if you try to go simpler but have a lot of work to do.
It’s also easy to teach to designers.
It’s also easy to teach to designers.
>learning what subset of HTML and CSS email clients render
You can use Table and all its related fields, span, h_, and p. Anything else is risky.
For CSS you can set the font color and size. Setting a font itself is risky. Avoid using anything else including margins and padding as these largely don't work properly. multi layered tables are your margin and padding system. You also can only use inline styles. No classes, style tags or linked styles.
Thats about it for email. Have fun.
You can use Table and all its related fields, span, h_, and p. Anything else is risky.
For CSS you can set the font color and size. Setting a font itself is risky. Avoid using anything else including margins and padding as these largely don't work properly. multi layered tables are your margin and padding system. You also can only use inline styles. No classes, style tags or linked styles.
Thats about it for email. Have fun.
Great! Now document it, create a getting started template, some component snippets, and examples, and you basically have a project that I want in my toolkit.
Not being snarky here: Isn't that what MJML is? It has components and examples and does all the nasty nesting table hacks for you.
Asking because all I know of it is from their site. I have not used it myself. Does it have its own glitches that come along during the attempt to patch over other glitches?
Asking because all I know of it is from their site. I have not used it myself. Does it have its own glitches that come along during the attempt to patch over other glitches?
No, it emphasizes itself over standards, and promotes compiling beyond the scope of inlining CSS. That's enough to turn me off. It's self serving. It's not serving my needs.
https://maizzle.com/ does that—of course, you'll then have to deal with using tables to layout content manually instead of using MJML's abstractions.
[deleted]
Mind you, I haven't used this in too long, but when I did I don't recall any issues.
https://get.foundation/emails/zurb-stack.html
https://get.foundation/emails/zurb-stack.html
There's a big problem with Foundation for Emails right now - the Saas workflow requires Node v10, which is now unsupported. You can't easily start a new project. It's unclear if this will ever get fixed.
[deleted]
I'd argue against frameworks and for providers to simply update the HTML and CSS they support. Its still bloody tables.
I think HTML emails are unnecessary.
It's only useful for advertising, marketing and tracking.
If you want to show fancy css and design, link a website.
If email was used as what it was designed for, writing electronic letters to each other and not spam and ads and marketing, we wouldn't have any of these problems.
I can't agree. I quite like html email. I just wish that it had an extremely cutdown subset (just colors, a few "header" sizes, italic, bold, underlined links), NO CSS allowed, no specifying of fonts other than say mono or "other". Maybe inline images links so that attached images could insert. No tables. Only <li> or <ul> Such a system would still be completely readable as plain old text. Now everyone thinks they have to use the kitchen sink approach or that there's not a middle ground.
I 100% agree.
I would love something like very simplistic markup, doesn't even have to be HTML. Just something to inline some images and differentiate text.
Everything else is just horrible.
I get so many emails with basically websites in them, but when you click on a product, the deep link is broken and you just end up on the storefront.
I'd much prefer a small text that talks about the product and explains a few things and then a working link to that product.
I would love something like very simplistic markup, doesn't even have to be HTML. Just something to inline some images and differentiate text.
Everything else is just horrible.
I get so many emails with basically websites in them, but when you click on a product, the deep link is broken and you just end up on the storefront.
I'd much prefer a small text that talks about the product and explains a few things and then a working link to that product.
You should take a look at https://heml.io/
Can you not send lorem ipsum as the text/plain part of your MIME message? Please?
I suppose "Your mail program is broken and can't read our message. Please go to this URL" is worse, though.
I suppose "Your mail program is broken and can't read our message. Please go to this URL" is worse, though.
I actually appreciate them. Both are high-quality signals for "this is something I don't care about", so they're great for filters.
I would pay an extra $0.10 per month to any service which offered plaintext only emails... Ah, a man can dream.
In Fastmail’s webmail:
Settings → Preferences → Show advanced preferences → Reading → View HTML, select Always display messages in plain text.
Settings → Preferences → Show advanced preferences → Compose & Reply → Compose format, select Plain text, plus untick When replying, use the same format as the original message.
I don’t think this is such a rare feature, though it’s generally not made obvious at least.
Settings → Preferences → Show advanced preferences → Reading → View HTML, select Always display messages in plain text.
Settings → Preferences → Show advanced preferences → Compose & Reply → Compose format, select Plain text, plus untick When replying, use the same format as the original message.
I don’t think this is such a rare feature, though it’s generally not made obvious at least.
Sorry, I suppose I wasn’t very clear. I do this through Posteo and Tutanota already (though perhaps you could sell me on Fastmail with your insider knowledge ;).
What I mean is I wish companies would send their transactional emails and newsletters in plaintext. Images and the like could be sent as attachments, as opposed to creepy weblinks that track your opens and IP and everything.
I would pay each company $0.10 if they offered me the option of receiving all their emails in plaintext like this.
What I mean is I wish companies would send their transactional emails and newsletters in plaintext. Images and the like could be sent as attachments, as opposed to creepy weblinks that track your opens and IP and everything.
I would pay each company $0.10 if they offered me the option of receiving all their emails in plaintext like this.
They'd probably make less money if you paid them, that's the problem.
And you'd also need to be able to somehow force them to <<only>> monetize you through direct payment, because what most companies do is, take your money <<and>> also sell your data, on top of that.
And you'd also need to be able to somehow force them to <<only>> monetize you through direct payment, because what most companies do is, take your money <<and>> also sell your data, on top of that.
If you hang out on HN a lot, I can see how you might think “most companies” are selling your data.
But this is hilariously false. Nowhere near “most” companies are selling your data.
In fact, an overwhelmingly vast majority of all businesses don’t sell your data. This is true inside Silicon Valley and even more true outside of the Valley.
Even in Silicon Valley, most companies understand that selling products and services to customers is more profitable than trashing a customer relationship by selling a customer’s personal info to third parties.
But this is hilariously false. Nowhere near “most” companies are selling your data.
In fact, an overwhelmingly vast majority of all businesses don’t sell your data. This is true inside Silicon Valley and even more true outside of the Valley.
Even in Silicon Valley, most companies understand that selling products and services to customers is more profitable than trashing a customer relationship by selling a customer’s personal info to third parties.
They don't sell it. But they entrust a lot of it to disreputable 3rd parties, who exist to track me all over the internet and then try to show me ads.
But possibly only because they haven't yet added 'tech' to the hip abbreviation of their industry, and realised that data is valuable, possibly more valuable than whatever their actual business is?
I think people use 'selling my data' as an (inaccurate, sure) shorthand for 'collecting so much data about me and I don't really trust them not to sell it at some point'.
I think people use 'selling my data' as an (inaccurate, sure) shorthand for 'collecting so much data about me and I don't really trust them not to sell it at some point'.
Handing it over during company acquisition is a form of sale.
I used to think that was true. But these days, I think a huge portion of companies are placing advertising or user tracking software on their websites produced by advertisers or user tracking vendors who DO capture and sell the data.
You nailed it. Since the original post is about email, I'll use LiveIntent as an example. Does the New York Times sell my personal data? Maybe, but not egregiously. But they use LiveIntent ad tags in their emails, and those tags leak a ton of data.
> In fact, an overwhelmingly vast majority of all businesses don’t sell your data.
That's because they haven't figured out how to. Or at least how to do it to make it worthwhile.
That's because they haven't figured out how to. Or at least how to do it to make it worthwhile.
Almost every mom-and-pop store sells your data to Facebook & co. That's what those fidelity cards are for. I didn't realize that either, until recently.
Secondly, we're all doomed. I recently read an article about Amazon's ad division being as big as AWS and growing as fast, if not faster:
https://www.ben-evans.com/benedictevans/2021/3/14/do-amazon-...
If even AWS isn't bigger and isn't growing faster than ads, what hope is there, really, for someone trying to just sell stuff?
Secondly, we're all doomed. I recently read an article about Amazon's ad division being as big as AWS and growing as fast, if not faster:
https://www.ben-evans.com/benedictevans/2021/3/14/do-amazon-...
If even AWS isn't bigger and isn't growing faster than ads, what hope is there, really, for someone trying to just sell stuff?
Maybe not directly, but a huge number of companies use tools that involve data selling, even if the company doesn't realize it. Once a marketing guy sent me a LinkedIn tracking tag to put on our website for conversion tracking. It quickly became clear he didn't know anything about what LinkedIn would do with the information. I think that stuff happens all the time.
Until recently, I worked for a company that published email newsletters and they still sent a text version along with HTML. It started back in the Blackberry days and continued because we thought it made our emails look more credible for corporate email filters.
That's about three levels deeper than most users are comfortable navigating, and as such only a negligible fraction of users will ever see this setting, understand what it does, and change it. Too bad every enterprise solution defaults to HTML anyway.
I wrote out the full path to it, but Preferences is the default page in Settings, and Reading and Compose & Reply are just sections inside it. So it’s actually more like “go to Settings, click Show advanced preferences at the bottom of the page, and search for ‘plain’”. And yeah, it is an advanced preference, whether you’d prefer otherwise or not.
Only a negligible fraction of users care about this feature and it only needs to be toggled once so it's clearly in the right place.
Most users probably don't care about HTML versus plaintext emails. The ones that do care would be the ones willing to pay $0.10 extra per month to enforce plaintext receipt, or willing to dig through a few levels of configuration to enable plaintext receipt.
TricepMail has granular/heritable switching between plain text or HTML, with or without images. For example, if you have a mailbox set to plain text but receive an email that you would like to render as HTML, it's just one click away for either the entire thread or just that message.
[deleted]
We are soon opening https://c1.fi - Horde webmail (https://wm.c1.fi) can do this.
(Preferences -> Mail -> Composition -> Default method to compose messages: "Plain Text")
(Preferences -> Mail -> Composition -> Default method to compose messages: "Plain Text")
One past thread:
Can I Email: ‘Can I Use’ for email - https://news.ycombinator.com/item?id=20948826 - Sept 2019 (196 comments)
Can I Email: ‘Can I Use’ for email - https://news.ycombinator.com/item?id=20948826 - Sept 2019 (196 comments)
Continuously modifying the URL with the search term wreaks havoc on tab history. Why not wait for the user to finish typing first?
They should just use history.replaceState() instead of history.pushState().
I have no clue why something this obvious is not taken care of.
I really don't like HTML emails as they very often break with my dark theme. Especially those in Outlook, dark blue on dark gray is not very visible. I'd like to have only plain text emails, but some website do not put text version of their mails (notifications...).
"Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should."
On a very similar discussion (e-mail feature bloat; particularly HTML mail) I once heard somebody describe the software developers involved to have suffered from "Beach Boy Syndrome" (wouldn't it be nice if...)
I've been using thunderbird for probably 15 years and have forgotten about html emails. I can imagine they are popular but it is probably the great fishing surface the average user is exposed to.
I wish people didn’t use html at all for emails…
First thing I do when I install Thunderbird on a new computer: disable HTML, enable monospace font.
Yeah, receiving email in html format is painful. With text, I can look at them the way I want.
I still only send plaintext myself, but clearly that ship has sailed. Many mailers don't even bother adding a proper text/plain alternative anymore.
I caved in and replaced mutt with Thunderbird personally. Not only for properly displaying HTML, but it was a big reason. Thunderbird sucks massively for composing plain text emails though, and no simple way to integrate an external editor...
I caved in and replaced mutt with Thunderbird personally. Not only for properly displaying HTML, but it was a big reason. Thunderbird sucks massively for composing plain text emails though, and no simple way to integrate an external editor...
> I caved in and replaced mutt with Thunderbird personally. Not only for properly displaying HTML, but it was a big reason. Thunderbird sucks massively for composing plain text emails though, and no simple way to integrate an external editor...
Have you considered emacs with notmuch and the Gnus renderer? It displays most HTML emails well, and when it doesn’t then a browser is just a quick ‘. b’ away. And of course there’s no need to integrate an external editor, because it’s integrated within the editor!
As a plus, it is simply amazing how quickly one can search local email.
Have you considered emacs with notmuch and the Gnus renderer? It displays most HTML emails well, and when it doesn’t then a browser is just a quick ‘. b’ away. And of course there’s no need to integrate an external editor, because it’s integrated within the editor!
As a plus, it is simply amazing how quickly one can search local email.
I wish I could set up automatic replies to mails lacking plain text.
How would you support formatted text in email, then?
Please don't say "there shouldn't be formatted text in email." That's not a reasonable position.
Please don't say "there shouldn't be formatted text in email." That's not a reasonable position.
I’m not saying it’s reasonable, I’m just saying I would prefer it. I also would prefer websites without ads and social networks without arbitrary “community rules” but it’s not going to happen.
> How would you support formatted text in email, then?
RFC 1896 specifies text/enriched: https://datatracker.ietf.org/doc/html/rfc1896
And of course nowadays there is Markdown, which basically codifies a lot of earlier plain-text formatting conventions.
> Please don't say "there shouldn't be formatted text in email." That's not a reasonable position.
I don’t know about that, really. We got by fine with plain text messages for decades, and the formatting conventions were good enough to convey meaning and nuance.
RFC 1896 specifies text/enriched: https://datatracker.ietf.org/doc/html/rfc1896
And of course nowadays there is Markdown, which basically codifies a lot of earlier plain-text formatting conventions.
> Please don't say "there shouldn't be formatted text in email." That's not a reasonable position.
I don’t know about that, really. We got by fine with plain text messages for decades, and the formatting conventions were good enough to convey meaning and nuance.
"We got by" is a bad argument.
Once email was in wide use by the general public, easy formatting was inevitable. HTML was everywhere, and so was the path of least resistance.
I thought it awful at the time, but "at the time" was literally more than two decades ago. HTML email is fine. MOST mail I get, professionally, has some formatting in it now. MOST mail I send probably does, too, to increase what a mentor of mine used to call "scan value."
Could I put all that in a Word doc and email THAT instead? Sure. But that would be a huge pain in the ass.
Once email was in wide use by the general public, easy formatting was inevitable. HTML was everywhere, and so was the path of least resistance.
I thought it awful at the time, but "at the time" was literally more than two decades ago. HTML email is fine. MOST mail I get, professionally, has some formatting in it now. MOST mail I send probably does, too, to increase what a mentor of mine used to call "scan value."
Could I put all that in a Word doc and email THAT instead? Sure. But that would be a huge pain in the ass.
We got by fine for thousands of years without computers at all
If by fine you mean the life style people had in the 12th century, I’ll pass and stick with computers..
I was making the point that surviving without something in the past or currently is no reason not to improve it.
Improvements are awesome! That’s why I linked to the text/enriched RFC. I really wonder if anyone who downvoted actually read it, or just emotionally reacted.
I don’t think that HTML emails are really an improvement: full-fledged HTML engines bring in too many opportunities for exploits and privacy loss. They definitely add capability, but at too high a cost IMHO.
In general, I think that our industry would benefit from asking ‘can we?’ less and instead asking ‘ought we?’ more.
I don’t think that HTML emails are really an improvement: full-fledged HTML engines bring in too many opportunities for exploits and privacy loss. They definitely add capability, but at too high a cost IMHO.
In general, I think that our industry would benefit from asking ‘can we?’ less and instead asking ‘ought we?’ more.
Can't argue with your final point at all.
However, my thread is more "can we do it differently?" instead of "maybe we shouldn't do it at all"
I agree, HTML isn't right for email.
Some different approach, possibly a markdown variant, with decent style support (basic css like background colours, fonts, like markdown themes in a code editor), why not explore that.
There's no reason emails need to be plain. RTF is a horrible format, markdown is much more prevalent and easy to make a simple UI formatter that obeys the standard for non technical users.
However, my thread is more "can we do it differently?" instead of "maybe we shouldn't do it at all"
I agree, HTML isn't right for email.
Some different approach, possibly a markdown variant, with decent style support (basic css like background colours, fonts, like markdown themes in a code editor), why not explore that.
There's no reason emails need to be plain. RTF is a horrible format, markdown is much more prevalent and easy to make a simple UI formatter that obeys the standard for non technical users.
I'm fine with HTML myself, actually; it's stuff like CSS that I'm more worried about.
There are plenty of use cases for <li>/<h1>/<em> in emails, and with some nice default user styles they can give everyone a pleasant experience.
Sadly, CSS is often applied and the HTML people write is often broken.
There are plenty of use cases for <li>/<h1>/<em> in emails, and with some nice default user styles they can give everyone a pleasant experience.
Sadly, CSS is often applied and the HTML people write is often broken.
You say that, but then a couple of times a month i get emails from a certain cultural society that for some reason always come out with the main text in one giant, one letter wide column… Both on the phone and outlook webmail!
This is going to be really useful to me as someone who doesn't really do this kind of thing. Very timely.
But don't put every keypress from my searches into my browser history.
But don't put every keypress from my searches into my browser history.
My first thought was that the higher on the list a client is, the more vulnerable it is.
Am I wrong with this assumption?
Am I wrong with this assumption?
I would say that, generally, higher complexity results in more possible attack vectors. Give that assumption, any client high on the list has more attack vectors than ones down the list.
I also think, though, that any open source client likely does a good job regardless of feature density, since its likely going to use well vetted code in core components.
Saying that, for example, Microsoft's or Apple's code isnt well vetted is unfair, but the amount of eyes that have seen the Microsoft html renderer vs the, say, WebKit one, is likely smaller and less diverse.
I also think, though, that any open source client likely does a good job regardless of feature density, since its likely going to use well vetted code in core components.
Saying that, for example, Microsoft's or Apple's code isnt well vetted is unfair, but the amount of eyes that have seen the Microsoft html renderer vs the, say, WebKit one, is likely smaller and less diverse.
Yes.
I love companies that send both HTML and plain text!
…as long as they contain the same content. I've seen e-mails where the HTML content is up to date, and the plain text part contains whatever was being sent a couple years ago, and hasn't been updated since then. Got me quite confused until I figured it out.
I like the AMP for email table: https://www.caniemail.com/features/amp/
What standard/RFC does this site pull from? The list of features a client is expected to support seems to be pretty arbitrary.
Its arbitrary cause there is no RFC about the ah-hoc choices email client softwares have made over the years that have kinda become de facto "standards"
https://github.com/hteumeuleu/caniemail
This is specifically focused at HTML specs/features, and a fork of https://github.com/Fyrd/caniuse
Targeting HTML rendering engines which are email clients.
Fortunately (at least for some of the newer features to be included) Links to MDN are available, and caniuse both link to we spec). CSS min for example is working draft. https://www.w3.org/TR/css-values-4/#math-function
With 90% desktop/mobile browser general usage support, 50% email usage support.
This is specifically focused at HTML specs/features, and a fork of https://github.com/Fyrd/caniuse
Targeting HTML rendering engines which are email clients.
Fortunately (at least for some of the newer features to be included) Links to MDN are available, and caniuse both link to we spec). CSS min for example is working draft. https://www.w3.org/TR/css-values-4/#math-function
With 90% desktop/mobile browser general usage support, 50% email usage support.
AFAIU this is a fork of caniuse.com; the features it tracks are probably a strict subset of those.
The feature definitions seem to be maintained manually, at https://github.com/hteumeuleu/caniemail/tree/master/_feature...; assuming it follows the caniuse.com community model, information about supported browsers is similarly crowdsourced.
The feature definitions seem to be maintained manually, at https://github.com/hteumeuleu/caniemail/tree/master/_feature...; assuming it follows the caniuse.com community model, information about supported browsers is similarly crowdsourced.
Weird to see Thunderbird for Mac and Windows perform so differently. Anyone knows what’s up with that?
(And what about Linux?)
(And what about Linux?)
From what I can see, they haven't tested most of the features in Thunderbird for Windows.
From my experience, all versions (Windows, macOS, Linux) have the same features.
From my experience, all versions (Windows, macOS, Linux) have the same features.
I made the mistake of giving too many companies my email address when those stupid black-the-page popups come up asking for my email. I am in the process of unsubscribing from every one of those emails; there is usually a small “unsubscribe” link at the bottom of them, and they are usually pretty good about honoring unsubscription requests.
These days, I disable Javascript on any site which has the audacity to put a popup in the middle of the page as I am reading it. Any site with is not readable without Javascript is one I leave and don’t go back to.
The kinds of sleazy outfits which do not honor unsubscribes are the kinds of places email providers are really good about black listing.
These days, I disable Javascript on any site which has the audacity to put a popup in the middle of the page as I am reading it. Any site with is not readable without Javascript is one I leave and don’t go back to.
The kinds of sleazy outfits which do not honor unsubscribes are the kinds of places email providers are really good about black listing.
This seems pretty useful. I'm actually working on a project right now (https://postheat.com) to automate all the styling and html for devs and I've had to learn most of this the hard way...
I think you need some example search b/c I was not sure how to use the tool at first.
I think you need some example search b/c I was not sure how to use the tool at first.
Neat site!
We use MJML to ensure compatibility in all mail clients, which works fine. Although MJML is much less flexible than pure HTML.
We use MJML to ensure compatibility in all mail clients, which works fine. Although MJML is much less flexible than pure HTML.
I still prefer text-only emails. I block as much external content as possible and usually those marketing and elaborate designs are all broken. It is very rare that I allow exceptions.
That being said, I can see the usefulness of this tool for developers, I just wish people would rely more on plain text.
That being said, I can see the usefulness of this tool for developers, I just wish people would rely more on plain text.
I find MJML (Mailjet Markup Language) to be a solution for many headaches.
Only 50% support for <marquee>? Where is this world going.
previous discussion: https://news.ycombinator.com/item?id=20948826
It would be great if the JSON data could be easily plugged into a linter so you could quickly validate if you are likely to have issues on a given client or not.
[deleted]
[deleted]
If that can be applied on a complete html file, it would be great. Take the html, and tell the user which tags will likely cause problems.
I could not even understand what the site did. :-(
It's tempting to make shouldiemail.com and just answer "No" for all these features. Seriously though, it must be years between every time I see an HTML email which would not have been improved by being plain text.
What the average HN user and the average user want is worlds apart. The average person likes their emails to be nicely designed like a website with blocks of colour and the site logos.
When they see a plain text email from a site they would be more likely to think they are being scammed than to be impressed at its simplicity and ability to display in the terminal.
When every website is hacking around broken table layouts to get them to render in outlook (essentially Word), something is wrong and should be fixed.
When they see a plain text email from a site they would be more likely to think they are being scammed than to be impressed at its simplicity and ability to display in the terminal.
When every website is hacking around broken table layouts to get them to render in outlook (essentially Word), something is wrong and should be fixed.
I posit that the average user doesn't want to put the time into reading plain text to find out if the email is worth their attention, images and colours are easier and quicker to process. A lot of information can be communicated quickly with some photos and a nicely formatted graphically rich message, probably with a large link button that takes the user to a relevant web page for further engagement.
This is not an endorsement of the practice, just an observation.
This is not an endorsement of the practice, just an observation.
But do they really? Most those "nicely designed" emails, to be honest, are spam. Either outright spam, like v14g4 and p3n1s pills (modern mail systems deal with those well enough), or only slightly more respectable spam like "you bought in our store once, so now we will hound you forever with ads for our good and services that you don't need anymore".
Among this sea of garbage, there are rare islands of useful updates - like genuine newsletters I subscribed to, or email from my doctor about test results, or reminder from my bank that they are going to deduct that car payment, whether I like it or not, so there better be money there, etc. And of course Amazon shipping notifications! If all those need any HTML, then only the most rudimentary one.
Of course, if you asked a user whether they'd want to get ugly marketing spam or beautiful one, I guess they'd choose the beautiful one. But that's not the right thing to ask.
Among this sea of garbage, there are rare islands of useful updates - like genuine newsletters I subscribed to, or email from my doctor about test results, or reminder from my bank that they are going to deduct that car payment, whether I like it or not, so there better be money there, etc. And of course Amazon shipping notifications! If all those need any HTML, then only the most rudimentary one.
Of course, if you asked a user whether they'd want to get ugly marketing spam or beautiful one, I guess they'd choose the beautiful one. But that's not the right thing to ask.
This is absolutely not my experience. Spam uses HTML formatting, sure, but it's not "nicely designed".
"Nicely designed" emails are things like flight confirmations, invoices, shipping notices, and that kind of transactional email. The common thread is that some entity with Real Money To Spend on a graphic designer is sending a (usually form) email to lots of people. Most spam outfits do not have those kinds of resources, especially since they need to change up their emails constantly to avoid spam filters.
The closest I would say that the "pretty" stuff gets to spam is newsletters and particularly political fundraising emails; I'm on a lot of political party lists after spending copious college free time working on campaigns.
"Nicely designed" emails are things like flight confirmations, invoices, shipping notices, and that kind of transactional email. The common thread is that some entity with Real Money To Spend on a graphic designer is sending a (usually form) email to lots of people. Most spam outfits do not have those kinds of resources, especially since they need to change up their emails constantly to avoid spam filters.
The closest I would say that the "pretty" stuff gets to spam is newsletters and particularly political fundraising emails; I'm on a lot of political party lists after spending copious college free time working on campaigns.
The common thread about those non-spam transactional e-mails you mention is also that they're usually barely above plaintext. They usually contain some minimally styled table, and some of the company colors. Maybe their logo somewhere. That's in stark contrast from the spam these same companies send, which is where all that "Real Money To Spend on a graphic designer" goes. Compare e.g. the spam PayPal sends you vs. the e-mails confirming payments you've made. In my experience, this is pretty universal.
And speaking of universal heuristic, in my experience, the quality and relevance of content is strongly inversely correlated with the quality of design. The prettiest websites out there are ones that deliver negative value. The best designed (according to modern trends) user interfaces are the ones with worst ergonomy, wasting user time the most.
And yes, the subset of spam that's most recognized - ED pills, reproductive organ enlargement, members of royalty looking for help managing their finances - they tend to be very simply designed. But their distinguishing feature isn't simplicity of design. It's the carelessness. Typos, bad grammar, highly visible formatting mistakes, etc. When, on occasion, one of that "old school" spam messages tries to pose as a legit transactional e-mail, you can see through the deception by noticing the carelessness in replicating the design of the company being impersonated.
And speaking of universal heuristic, in my experience, the quality and relevance of content is strongly inversely correlated with the quality of design. The prettiest websites out there are ones that deliver negative value. The best designed (according to modern trends) user interfaces are the ones with worst ergonomy, wasting user time the most.
And yes, the subset of spam that's most recognized - ED pills, reproductive organ enlargement, members of royalty looking for help managing their finances - they tend to be very simply designed. But their distinguishing feature isn't simplicity of design. It's the carelessness. Typos, bad grammar, highly visible formatting mistakes, etc. When, on occasion, one of that "old school" spam messages tries to pose as a legit transactional e-mail, you can see through the deception by noticing the carelessness in replicating the design of the company being impersonated.
> And speaking of universal heuristic, in my experience, the quality and relevance of content is strongly inversely correlated with the quality of design. The prettiest websites out there are ones that deliver negative value. The best designed (according to modern trends) user interfaces are the ones with worst ergonomy, wasting user time the most.
This is just plain untrue, and seems to color your impression of email as well. See e.g. Delta vs Southwest (more polished look is more ergonomic site/app), or New Relic vs Datadog public-facing sites (indistinguishable in "quality" of the design, for competing products where IMO Datadog is better).
What are some examples that put the inverse correlation in your mind?
This is just plain untrue, and seems to color your impression of email as well. See e.g. Delta vs Southwest (more polished look is more ergonomic site/app), or New Relic vs Datadog public-facing sites (indistinguishable in "quality" of the design, for competing products where IMO Datadog is better).
What are some examples that put the inverse correlation in your mind?
V1gr4 spam isn't nicely designed, but marketing we-arent-really-spam-because-we-have-unsubscribe-link spam - surely is. That includes political marketing too, of course, selling politicians is just another form of selling.
[deleted]
> Most those "nicely designed" emails, to be honest, are spam.
Indeed. The number of HTML elements in an email scales pretty linearly with the probability of it being spam.
Plain text is almost 100% certain not spam.
Indeed. The number of HTML elements in an email scales pretty linearly with the probability of it being spam.
Plain text is almost 100% certain not spam.
I run an email forwarding service[1] so I deal with spam a lot.
Spam usually has bad formating, mixed charset, old/broken layoyt etc.
Most of time, spam are odd designs. Example they only have HTML and didn't have the corresponding plain text part. They have large pictures and too little text, they have many "invisible" part so that hide behind element to trick you to click the wrong thing.
Even in plain-text, spam tend to include random links, very long text, weird chracter etc
A nicely design, or a plain-text emails(only plain text) with nice format all are good signal of non-spam.
In other word, consistency is signal of non-spam emails. But sometime marketing emails-which you never explicitly subscribe to, you just register for an account and got marketing emails, can also be consider spam, but from google/hotmail point of view they don't consider these are spam and that's reason they have Promotion tab to put thing in there
---
[1] https://hanami.run
Spam usually has bad formating, mixed charset, old/broken layoyt etc.
Most of time, spam are odd designs. Example they only have HTML and didn't have the corresponding plain text part. They have large pictures and too little text, they have many "invisible" part so that hide behind element to trick you to click the wrong thing.
Even in plain-text, spam tend to include random links, very long text, weird chracter etc
A nicely design, or a plain-text emails(only plain text) with nice format all are good signal of non-spam.
In other word, consistency is signal of non-spam emails. But sometime marketing emails-which you never explicitly subscribe to, you just register for an account and got marketing emails, can also be consider spam, but from google/hotmail point of view they don't consider these are spam and that's reason they have Promotion tab to put thing in there
---
[1] https://hanami.run
That is completely antithetical to my experience as mail server operator and someone who gets a lot of spam.
Nearly 100% of spam is plaintext, a small fraction uses badly designed HTML that barely displays in the client.
Nearly 100% of spam is plaintext, a small fraction uses badly designed HTML that barely displays in the client.
This may come down to whether you consider marketing email from legitimate businesses to be "spam" or if you reserve the term for the more scammy/seedy type of mail.
I unsubscribe from marketing mails, those are legally required to have an unsubscribe link in them. You should try clicking on that if you don't like marketing mail. If they don't stop you can threaten legal action in both EU and US without issue.
If it doesn't have this link, it's spam. If it's trying to get me to buy something I didn't explicitly wishlist on a store, it's spam. If it's unsolicited marketing, it's spam.
And even if I were to include all marketing email, including those I am interested in, then plaintext mail would still constitute the majority of spam mails I receive.
If it doesn't have this link, it's spam. If it's trying to get me to buy something I didn't explicitly wishlist on a store, it's spam. If it's unsolicited marketing, it's spam.
And even if I were to include all marketing email, including those I am interested in, then plaintext mail would still constitute the majority of spam mails I receive.
I personally found out that it's easier and faster to train my spam filter to move these mails into the spam folder. (I'm using claws-mail with bogofilter, which works quite well.)
Whenever I have to interact with a company, I check the spam folder for their replies.
The majority of mails in my spam folder is html mail.
Whenever I have to interact with a company, I check the spam folder for their replies.
The majority of mails in my spam folder is html mail.
The majority of mails in my spam folder is plaintext mail. Second place are the extremely malformed HTML mails. Almost any wellformed HTML mail I receive is solicited at minimum.
I can recommend using the unsubscribe link if you forgot to uncheck the newsletter checkbox during registration. Alternatively send them a mail to A) remind them of the SPAM-CAN act or your local equivalent legislation and B) that they should delete your mail from the newsletter. That works almost always, if not you can always threaten legal action (where I live, that's an easy 600€ of profit in a courtroom).
I can recommend using the unsubscribe link if you forgot to uncheck the newsletter checkbox during registration. Alternatively send them a mail to A) remind them of the SPAM-CAN act or your local equivalent legislation and B) that they should delete your mail from the newsletter. That works almost always, if not you can always threaten legal action (where I live, that's an easy 600€ of profit in a courtroom).
It's safer as well. Some (most?) of those "unsubscribe" links have a unique ID hooked in with your email in some database so they know that they have a hit and can send more email to you.
Well, they need something to be able to tell which email to remove from their DB too.
Not all is as sinister as it looks.
The simply solution is to just can any senders that don't respond to unsubscribe requests. But those will be just as bad in plaintext as in HTML, so I don't see why Plaintext means it's not spam, they can do the same thing Plaintext.
Not all is as sinister as it looks.
The simply solution is to just can any senders that don't respond to unsubscribe requests. But those will be just as bad in plaintext as in HTML, so I don't see why Plaintext means it's not spam, they can do the same thing Plaintext.
Any unsolicited marketing is spam, unsubscribe link or not.
That's... what I said. I mentioned the unsubscribe link for solicited marketing mails, where that is in fact relevant. Unsolicited email would be pretty damn illegal in my home country to begin with (and a GDPR violation).
It is illegal but very common. Many of those emails with unsubscribe links are unsolicited. They either spam all their former customers no matter if they have opted in or not or they just buy links. Yes, the unsubscribe links work but what they do is in obvious violation if the gdpr and other laws.
Very few companies would risk those lawsuits, especially in Europe the fines can get rather exponential for repeat violators and I don't think it's much different in the US either. If the unsubscribe works, that is the end of the story for me, and a reminder to check for small newsletter checkboxes when signing up to things.
I very rarely get marketing mails from any reputable company that are completely unsolicited. In most cases it's a followup from trying out an offering or updates to products I'm using or are adjacent to those. If I'm not interested, I either ignore them or unsubscribe if it's repeatedly not interesting.
This is a much more effective "spam" strategy compared to "all HTML is spam".
I very rarely get marketing mails from any reputable company that are completely unsolicited. In most cases it's a followup from trying out an offering or updates to products I'm using or are adjacent to those. If I'm not interested, I either ignore them or unsubscribe if it's repeatedly not interesting.
This is a much more effective "spam" strategy compared to "all HTML is spam".
Spam sent to different domains (especially in different TLD) tends to be different so experience can be different.
In my observations badly formatted spam exists, but have big intersection with the spam which is relatively easy to filter out. Nicely formatted HTML spam on other hand is hard to filter because the only difference with legitimate marketing email is lack of any consent from the sender. Sure I can hit an unsubscribe link and my be never will get spam from the same domain again, but spammer will know that this email is active and will include the address in spam send on behalf of other customers.
In my observations badly formatted spam exists, but have big intersection with the spam which is relatively easy to filter out. Nicely formatted HTML spam on other hand is hard to filter because the only difference with legitimate marketing email is lack of any consent from the sender. Sure I can hit an unsubscribe link and my be never will get spam from the same domain again, but spammer will know that this email is active and will include the address in spam send on behalf of other customers.
Well, that is where the line of solicited and unsolicited mails fall, spammers are generally unsolicited (so no previous mail address confirmation), their unsubscribe links won't work and >90% of them are plaintext with the remainder having bad or illformed HTML. 99.8% of marketing mails I get have an unsubscribe link that works because it forgot to uncheck the newsletter when signing up, those are not an issue. And those are usually HTML mails with well formed formatting.
A quick scan of my inbox and spam folders would refute this
I just looked through my Junk folder and it took me about 30 seconds to find an email that was sent as plain text. Most of this time was spent digging through Mail's menus to figure out how to show the raw message.
My experience is opposite. I have never received a scam email with HTML, is always plaintext that tried to mimic a regular conversation.
You must have a hell of a spam filter.
Unless it's from a Nigerian prince.
I'm pretty sure that this comment was sarcasm
[deleted]
yes, they do
> What the average HN user and the average user want is worlds apart. The average person likes their emails to be nicely designed like a website with blocks of colour and the site logos.
Do they? Do they really like it? Did anyone actually asked? And no, A/B testing your design's capability to trick the user into paying you money isn't measuring whether they like it or not.
I have an alternative proposal: average user just accepts what they're given, because they have no other choice. Nobody listens to their opinion (again, tracking and telemetry is not the same as listening to people). Abusive designs and patterns are adopted industry-wide very quickly, so there's rarely an opportunity for the user to vote with their wallet - after all, they can't choose something that's not available in the first place. On top of that, the average user lacks the mental models and language to conceptualize what is wrong and how much better technology could be if it was slightly less abusive. All they can do is accept that computers are annoying, and casually complain about this to friends and family.
Do they? Do they really like it? Did anyone actually asked? And no, A/B testing your design's capability to trick the user into paying you money isn't measuring whether they like it or not.
I have an alternative proposal: average user just accepts what they're given, because they have no other choice. Nobody listens to their opinion (again, tracking and telemetry is not the same as listening to people). Abusive designs and patterns are adopted industry-wide very quickly, so there's rarely an opportunity for the user to vote with their wallet - after all, they can't choose something that's not available in the first place. On top of that, the average user lacks the mental models and language to conceptualize what is wrong and how much better technology could be if it was slightly less abusive. All they can do is accept that computers are annoying, and casually complain about this to friends and family.
Users want nice shapes and color.
There's a reason the most popular media is video and images and the main social media platforms are practically platforms for sharing video and images.
The average person all over all the world is almost functionally illiterate (literacy level of a middle schooler or maybe high schooler, at best). They really, really don't want text. They'll only read as much as they have to, and they will definitely choose images over text if they can.
There's a reason the most popular media is video and images and the main social media platforms are practically platforms for sharing video and images.
The average person all over all the world is almost functionally illiterate (literacy level of a middle schooler or maybe high schooler, at best). They really, really don't want text. They'll only read as much as they have to, and they will definitely choose images over text if they can.
I don't even think it's a matter of liking or disliking, but more a matter of being blind to the standard formatting (something that most deal with on their jobs).
At the end of the day if you see another blob of text, you either skim through it looking for what matters or you just delete/archive it.
They could even hate it, but it just stands out for better and worst.
At the end of the day if you see another blob of text, you either skim through it looking for what matters or you just delete/archive it.
They could even hate it, but it just stands out for better and worst.
> Do they? Do they really like it? Did anyone actually asked?
Oh yeah, they do like it and want it. That is why they use it. And yes, I talked with a guy who was literally like "I like the emails colorful and such, but we found through testing developers respond better to plain, so I send plain to them".
Sometimes we are the odd ones and that is ok.
Oh yeah, they do like it and want it. That is why they use it. And yes, I talked with a guy who was literally like "I like the emails colorful and such, but we found through testing developers respond better to plain, so I send plain to them".
Sometimes we are the odd ones and that is ok.
> What the average HN user and the average user want is worlds apart. The average person likes their emails to be nicely designed like a website with blocks of colour and the site logos.
Taste is generated. Cool trendy startups make "nicely designed" emails, users come to expect that. If scam emails looked "nicely designed" and Google sent emails in plaintext, the "nicely designed" emails would be considered untrustworthy. As a counterpoint, an "average user" wants software to work, and forcing every email client to parse HTML (which is far outside the scope of what an email client should do, especially with html as complex as it is today) often breaks things in unexpected ways.
In my opinion, html and plaintext are both inappropriate for email. HTML is far too complex, and plaintext is a bit too simple. I think a markdown-like syntax would be the best balance, but I'm pretty sure that ship has sailed.
Taste is generated. Cool trendy startups make "nicely designed" emails, users come to expect that. If scam emails looked "nicely designed" and Google sent emails in plaintext, the "nicely designed" emails would be considered untrustworthy. As a counterpoint, an "average user" wants software to work, and forcing every email client to parse HTML (which is far outside the scope of what an email client should do, especially with html as complex as it is today) often breaks things in unexpected ways.
In my opinion, html and plaintext are both inappropriate for email. HTML is far too complex, and plaintext is a bit too simple. I think a markdown-like syntax would be the best balance, but I'm pretty sure that ship has sailed.
You'd love enriched text then: https://en.m.wikipedia.org/wiki/Enriched_text
As far as I know, only old (possibly pre-Tiger) Mail.app in Mac OS X used to produce it.
As far as I know, only old (possibly pre-Tiger) Mail.app in Mac OS X used to produce it.
This is cool, I may have to play around with it
From what I've seen from average user, they tend to struggle pasting text with the same font into their email reply, struggle to quote parts of the message or email hyperlinks in usable manner.
Thats what the average web dev thinks the average person wants.
And thus is what people have come to expect, sadly, IMHO. Except for the technically inclined/HN userbase. Though another comment said Germans prefer plaintext emails w/o attachments.
Wouldn't say that is entirely true. Germans prefer HTML mail that amounts to simple rich text, ie bold and italic fonts, possibly some color highlighting if you're really daring. Pure plaintext isn't that well appreciated.
> Except for the technically inclined/HN userbase.
This community is as much an echo chamber as anywhere else. Just because an opinion is common here doesn't mean it's correct or reflects the wider population.
This community is as much an echo chamber as anywhere else. Just because an opinion is common here doesn't mean it's correct or reflects the wider population.
Beauty is no quality in things themselves: It exists merely in the mind which contemplates them; and each mind perceives a different beauty. One person may even perceive deformity, where another is sensible of beauty; and every individual ought to acquiesce in his own sentiment, without pretending to regulate those of others. - Hume, D
§ https://plato.stanford.edu/entries/beauty/#ObjSub
§ https://plato.stanford.edu/entries/beauty/#ObjSub
A commercial project aims for profit, not public service. The previous post explains why they are popular demands. And it is natural for commercial project to satisfy popular demands.
QED: Beauty ≡ Profit
One oddity I've noticed is that Germans seem to like their emails in plain text, and without any attachments: https://news.ycombinator.com/item?id=15226022
I've corresponded with others, also German, and they had the same preferences, even if not as explicitly stated as the examples in my other comment there.
I've corresponded with others, also German, and they had the same preferences, even if not as explicitly stated as the examples in my other comment there.
We used to have our German newsletter available in plain text and styled. The vast majority of people chose the styled version. Not even 1 % picked text. No dark patterns involved, a simple radiobox. We do not offer the text version anymore.
How do you know that is what the average person likes or what they think? Are there any studies for these?
I’m not the person you are responding to and I’m also a software dev (ie. not the average user), but I prefer a nice looking email that includes some simple graphics and formatting. So that’s at least one person that prefers that kind of thing to a plain text email and I’m pretty sure I’m not alone. I think we can probably agree that there is a large subset of the population that likes “nice looking” websites, so why would emails be different.
> Now, with the emphasis on imagery across the web, users strongly preferred images that could be seen full screen or at a larger scale, looked high-quality, and showed detail clearly.
https://www.nngroup.com/articles/newsletters/ (2017)
https://www.nngroup.com/articles/newsletters/ (2017)
That article seems positively rife with weird assumptions, all to present email marketing in a favorable light. It's bad enough that I don't really trust the quote you gave from it.
> Because several of these constraints have been remedied over the years, many of the concerns that users had about subscribing have disappeared.
Read: Because we stopped asking permission and instead started spamming everybody who gave us their email address, people stopped thinking that not subscribing had any effect.
> The increase in sheer email volume over the years has created a scenario where people can’t possibly give all messages their full attention, so they care less about what they receive because they know they can easily ignore the noise or choose what they invest their time in.
Read: Our entire industry spams people so much that people know it's not worth reading.
> It’s no longer used strictly to describe unsolicited email messages. Participants in our study used the word “spam” to describe solicited marketing emails that they considered random, impersonal, irrelevant, with too much promotional hype, or coming in high volume.
Read: We required an email address for things that don't need one, then treated that as permission. How dare people consider our spam to be spam?
> Now that organizations are required to include an Unsubscribe link in their newsletters, this task has become easier.
If a company assumes that an email address given for identification can be used for marketing, or that it can be shared with third-parties/affiliates for marketing, then they are already pretty shady. I honestly have no way of knowing whether it's an actual Unsubscribe link, or whether it's a signal that the email address is actively read by a human and so should receive more spam.
> If users keep getting unwanted newsletters, the messages will start to backfire and become regular reminders that they’re annoyed with your company. Better to let them go.
This part I do agree with. Better still would be to not assume permission to send marketing to somebody just because there was a pre-checked both on a form.
> Because several of these constraints have been remedied over the years, many of the concerns that users had about subscribing have disappeared.
Read: Because we stopped asking permission and instead started spamming everybody who gave us their email address, people stopped thinking that not subscribing had any effect.
> The increase in sheer email volume over the years has created a scenario where people can’t possibly give all messages their full attention, so they care less about what they receive because they know they can easily ignore the noise or choose what they invest their time in.
Read: Our entire industry spams people so much that people know it's not worth reading.
> It’s no longer used strictly to describe unsolicited email messages. Participants in our study used the word “spam” to describe solicited marketing emails that they considered random, impersonal, irrelevant, with too much promotional hype, or coming in high volume.
Read: We required an email address for things that don't need one, then treated that as permission. How dare people consider our spam to be spam?
> Now that organizations are required to include an Unsubscribe link in their newsletters, this task has become easier.
If a company assumes that an email address given for identification can be used for marketing, or that it can be shared with third-parties/affiliates for marketing, then they are already pretty shady. I honestly have no way of knowing whether it's an actual Unsubscribe link, or whether it's a signal that the email address is actively read by a human and so should receive more spam.
> If users keep getting unwanted newsletters, the messages will start to backfire and become regular reminders that they’re annoyed with your company. Better to let them go.
This part I do agree with. Better still would be to not assume permission to send marketing to somebody just because there was a pre-checked both on a form.
Emails are incredibly easy to ab test given a sufficiently large audience size.
Fully agree. When we launched our service, we used really simple plain text mails and we had users complaining that they looking unprofessional and spammy. We didn't go crazy with our email design, and we're certainly not pushing the limits of what's possible to use in an email, but just adding a bit of color, a log and some text formatting made a big difference. Haven't heard a complaint since.
I looked at the mail I really wanted to read from the most reputable entities (banks, government, business partners,...). Usually there is a logo at the top and the rest is mostly plain text with minimal formatting. A nice, colorful email, sometimes from the same companies usually mean one thing: ad.
This is no different from snail mail, where important communication is usually on standard white paper while ads are high quality prints on nice goossy paper.
And obviously, "average users" notice the pattern. Just like my father who almost trashed an important tax-related mail just because it looked too nice, he thought it was an ad.
So the "average user" prefer to see nice ads, I can get that. But what the average user really prefers no ads at all.
This is no different from snail mail, where important communication is usually on standard white paper while ads are high quality prints on nice goossy paper.
And obviously, "average users" notice the pattern. Just like my father who almost trashed an important tax-related mail just because it looked too nice, he thought it was an ad.
So the "average user" prefer to see nice ads, I can get that. But what the average user really prefers no ads at all.
[deleted]
>The average person likes their emails to be nicely designed like a website with blocks of colour and the site logos.
I really don't think that that's true.
I really don't think that that's true.
This isn't an argument, it's merely contradiction!
Both the assertion and the contradiction are equally baseless.
I disagree; while fancy stylings can be excessive, being able to use things like screenshots, headings, and tables is very useful. Sure you can do images and tables through attachments, but that adds extra steps which are inconvenient.
Recently, I sent a longer-form announcement email and I think it really benefited from simple formatting. Headers that were visually distinct made it easier to parse, and in one place I set an image to float right which I felt made it less disruptive. I even set a max-width on the whole email, which I think works far better than the hard-wrapped text that some people write.
Almost every day, I find myself sending and receiving screenshots placed in context with some text and bullet points. Dare I say it: I love HTML emails
What’s lame is when there is no plaintext alternative. A clear sign of someone who does not wish to communicate with me.
It at least implies a certain lack of technical expertise on the part of organizations that send such HTML only emails. The same for when they put completely unformated garbage in the text part. If W3M can do a better job starting with their HTML email you have to ask yourself why they couldn't of done at least that instead of whatever they did.
> What’s lame is when there is no plaintext alternative.
Or worse yet, when the plaintext alternative version is broken/incomplete.
I regularly receive mail where the plaintext alternative version has templating variable names instead of actual values, where the html version has the values.
Also, systems that send mail where the plaintext alternative version is only something along the lines of “Your email client does not support HTML. Please read this newsletter at” and then a link. But of course, my client can read html too, I just have it set to view the plaintext version by default.
One of these days I will probably just set it to always prefer the html version instead. I use mutt, with elinks taking care of html to plain text conversion. I’ve been running my mail server for years.
But anyways it might soon be time for me to switch to hosted mail. I have a provider in mind.
Or worse yet, when the plaintext alternative version is broken/incomplete.
I regularly receive mail where the plaintext alternative version has templating variable names instead of actual values, where the html version has the values.
Also, systems that send mail where the plaintext alternative version is only something along the lines of “Your email client does not support HTML. Please read this newsletter at” and then a link. But of course, my client can read html too, I just have it set to view the plaintext version by default.
One of these days I will probably just set it to always prefer the html version instead. I use mutt, with elinks taking care of html to plain text conversion. I’ve been running my mail server for years.
But anyways it might soon be time for me to switch to hosted mail. I have a provider in mind.
Sometimes plain text alternative is so bad that one forced to use HTML version anyway. I've tried plain text emails in Atlassian Jira settings - emails it sends are badly formatted and have lots of empty lines, likely they make plaintext version from HTML one with something like `lynx --dump`.
If it was sent personally to you by somebody who knew your preference you might be right, but realistically the number of people who cares or who have any issue with HTML mails is going to be sub 0.1%, so it is almost certainly more a case of don't care, not worth considering.
You're against bold, italics, underline? Headings? Any image support at all?
Camel's nose, meet tent.
You mean bold, /italics/, and _underline_ ? Sure :)
Those are just ascii characters. You really don't want them to touch the font?
(If your client interprets them, then you're not actually asking for plain text anymore.)
(If your client interprets them, then you're not actually asking for plain text anymore.)
If the client chooses to interpret them, then the point of control is where it should be.
We still want to standardize it, though, right? Instead of a dozen different ad-hoc interpretations of the same message?
Making it unobtrusive enough to still look good when uninterpreted is a good goal. But that's very different from having nothing at all.
Making it unobtrusive enough to still look good when uninterpreted is a good goal. But that's very different from having nothing at all.
There's a very small set of text decorations which would suit virtually all cases.
And there was a long history (about 100 years) of monospaced, mono-sized, typographic conventions based on typewriters and cheap reproduction (carbon paper, spirit duplicators, xerography), before the desktop-publishing era brought us out of that in the 1980s. The problem with formatting is that, like Johnny Rocco in Key Largo, someone always wants more, and not for your benefit but theirs.[1]
#ThisIsWhyWeCannotHaveNiceThings
https://news.ycombinator.com/item?id=27114500
In the Web world, counter to an argument elsewhere in this thread (https://news.ycombinator.com/item?id=27113404), my experience is that Web design isn't the solution, Web design is the problem. Straight ASCII text (via w3m or other text-mode browsers), or Reader Mode (where supported) is vastly preferable to many, many nines worth of sites' prescribed designs.
One thought I've had is that user agents could provide, at user discretion, additional typographic control to sites. But for the basics you're limited to 7-bit (not 8) ASCII. Everything else is earned, and you'd best degrade very gracefully.
I've seen websites written where every individual paragraph has an explicitly-specified location. I've seen blogs written entirely in header-level tags. I've seen writers who add nonbreaking whitespace to the start of every paragraph. I've seen blink, marquee, and carousel abuse. I've seen foreground and background colours you wouldn't believe. Attack ships on fire off the shoulder of Orion....
________________________________
Notes:
1. https://invidious.snopyta.org/watch?v=ITs-YX1yQ7o
And there was a long history (about 100 years) of monospaced, mono-sized, typographic conventions based on typewriters and cheap reproduction (carbon paper, spirit duplicators, xerography), before the desktop-publishing era brought us out of that in the 1980s. The problem with formatting is that, like Johnny Rocco in Key Largo, someone always wants more, and not for your benefit but theirs.[1]
#ThisIsWhyWeCannotHaveNiceThings
https://news.ycombinator.com/item?id=27114500
In the Web world, counter to an argument elsewhere in this thread (https://news.ycombinator.com/item?id=27113404), my experience is that Web design isn't the solution, Web design is the problem. Straight ASCII text (via w3m or other text-mode browsers), or Reader Mode (where supported) is vastly preferable to many, many nines worth of sites' prescribed designs.
One thought I've had is that user agents could provide, at user discretion, additional typographic control to sites. But for the basics you're limited to 7-bit (not 8) ASCII. Everything else is earned, and you'd best degrade very gracefully.
I've seen websites written where every individual paragraph has an explicitly-specified location. I've seen blogs written entirely in header-level tags. I've seen writers who add nonbreaking whitespace to the start of every paragraph. I've seen blink, marquee, and carousel abuse. I've seen foreground and background colours you wouldn't believe. Attack ships on fire off the shoulder of Orion....
________________________________
Notes:
1. https://invidious.snopyta.org/watch?v=ITs-YX1yQ7o
I would be fine if my client would neatly format a limited markdown format and other clients supported entering it in a WYSIWYG fashion, as long as all the displayed content is part of the transmitted message (no further connection to the net) and the client is guaranteed not to execute any sender-supplied code or transmit any data when links or images are displayed.
I think you meant 𝗯𝗼𝗹𝗱, 𝘪𝘵𝘢𝘭𝘪𝘤, and u̲n̲d̲e̲r̲l̲i̲n̲e̲.
Just a heads up that screen readers will tend to read sentences like that as "I think you meant MATHEMATICAL BOLD SMALL B MATHEMATICAL BOLD SMALL O MATHEMATICAL BOLD SMALL L MATHEMATICAL BOLD SMALL D comma MATHEMATICAL ITALIC SMALL I MATHEMATICAL ITALIC SMALL T MATHEMATICAL ITALIC SMALL A MATHEMATICAL ITALIC SMALL L MATHEMATICAL ITALIC SMALL I MATHEMATICAL ITALIC SMALL C and U N D E R L I N E" and so on which can be extremely unpleasant
I don't get why you're being downvoted. Every time Unicode support or rich text formatting comes up on HN someone wants to show off how "smart" they are.
"Showing off" that you know some screenreaders do the wrong thing is not any more "smart".
I got an almost identical comment when I said HN doesn't support any formatting, except for italic and link formatting.
Inputting by hand (or maybe with a script - who cares anyway?) random Unicode characters to show that rich text is actually possible is the opposite of "smart" in a discussion between reasonable adults.
Inputting by hand (or maybe with a script - who cares anyway?) random Unicode characters to show that rich text is actually possible is the opposite of "smart" in a discussion between reasonable adults.
> I got an almost identical comment
Yep, that was me that time as well.
> Inputting by hand (or maybe with a script
I did it by hand. There are websites to do this, but I’m not interested in doing this for any regular purpose, so I don’t think I have them saved. Besides, it’s more interesting to do it manually; you learn things about how Unicode works if you involve yourself in the low-level details once in a while.
> the opposite of "smart" in a discussion between reasonable adults.
Or maybe it’s humorous? You know, fun?
Yep, that was me that time as well.
> Inputting by hand (or maybe with a script
I did it by hand. There are websites to do this, but I’m not interested in doing this for any regular purpose, so I don’t think I have them saved. Besides, it’s more interesting to do it manually; you learn things about how Unicode works if you involve yourself in the low-level details once in a while.
> the opposite of "smart" in a discussion between reasonable adults.
Or maybe it’s humorous? You know, fun?
> fun
Fun?!? On my HackerNews?!?
Burn the heretic!
Fun?!? On my HackerNews?!?
Burn the heretic!
I don't think you need to be so negative about this.
Most people are unaware that Unicode has that kind of character and even fewer people know what it does to screen readers.
The difference between showing off knowledge and trying to be show people a cool thing you know about is intent and it's REALLY hard to get that across on the internet.
Most people are unaware that Unicode has that kind of character and even fewer people know what it does to screen readers.
The difference between showing off knowledge and trying to be show people a cool thing you know about is intent and it's REALLY hard to get that across on the internet.
> it's REALLY hard to get that across on the internet
Agreed, that's why I like emojis, for example. They're whimsical, and they increase a bit the bandwidth of written communication.
Alas, HN doesn't support them because of reasons ¯\_(ツ)_/¯
Agreed, that's why I like emojis, for example. They're whimsical, and they increase a bit the bandwidth of written communication.
Alas, HN doesn't support them because of reasons ¯\_(ツ)_/¯
The GNKSA was the real deal. It was for Usenet but a lot of it applies to email too.
https://web.archive.org/web/20160417105503/http://www.gnksa....
https://web.archive.org/web/20160417105503/http://www.gnksa....
Not sure about every HTML being plain text but I do wish I had $20 for every overly image heavy email that has no meaning what so ever unless I do "show images." Don't brands understand a fair number of ppl have their email client *not* display images by default?
Unless you are using Mutt or similar I don't think anybody does not show images by default. I know thunderbird has no problem showing me images that are included in the email.
Remote images are a crime, break the ability to search ofline or keep a record of ones conversation but they have one key advantage for brands which is to spy on you.
Remote images are a crime, break the ability to search ofline or keep a record of ones conversation but they have one key advantage for brands which is to spy on you.
Rainloop web client used by Disroot and some others defaults to not showing images and needs you to click a button to display them. IIRC Protonmail is the same in its webmail.
The only non-web client I've used much in recent years is aerc, which is basically covered under "mutt" in this case.
The only non-web client I've used much in recent years is aerc, which is basically covered under "mutt" in this case.
My corporate Outlook email client does not show images by default if the sender is external.
Even if those images are embedded in the email?
Honestly I'm using Thunderbird only because of two things:
- Plain Text Mode
and
- uBlock Origin Extension is available (that can block also embedded JS)
People underestimate the attack vector of emails. I'm glad those scammers haven't figured out (at least until now) how XSS could work in Gecko with XUL. Heap spraying could easily be a thing, given that MS Outlook also still uses their outdated rendering engine.
- Plain Text Mode
and
- uBlock Origin Extension is available (that can block also embedded JS)
People underestimate the attack vector of emails. I'm glad those scammers haven't figured out (at least until now) how XSS could work in Gecko with XUL. Heap spraying could easily be a thing, given that MS Outlook also still uses their outdated rendering engine.
I typically compose all messages in Markdown and then convert that into rendered HTML. So if you believe in the expressiveness of Markdown (which I hope you do), then HTML rendering is absolutely necessary.
Unfortunately, desktop Outlook is miserable with HTML support [1]. In particular, code blocks and quotes become an unreadable mess. The only way that I've found to include readable code blocks is to copy from VS Code, which somehow has the magic HTML combination that Outlook understands.
[1] https://www.caniemail.com/clients/outlook/#windows
Unfortunately, desktop Outlook is miserable with HTML support [1]. In particular, code blocks and quotes become an unreadable mess. The only way that I've found to include readable code blocks is to copy from VS Code, which somehow has the magic HTML combination that Outlook understands.
[1] https://www.caniemail.com/clients/outlook/#windows
Why is it necessary? The whole point of markdown is that you may render it but it's also fine and easy to read when it remains plaintext.
If it's relevant enough for Github/Gitlab to render Markdown for the browser, clearly there's a visibility and aesthetic value to rendering.
FWIW, I just don't support HTML email and only for a small handful of services and senders do I ever get burned. If my email client did a pass over the HTML and gave me all the text followed by all the links that would be sufficient (right now I sometimes simulate that by opening up the raw MIME and grabbing what I need). Like, do we live in a world where this even matters? How is your life being made worse by people using these features? E-mail was explicitly designed in a way to support emails that have both HTML and non-HTML, and for people like us--"worst case"--the HTML can be stripped to text and it is fine.
Love plaintext but meanwhile, even in tech, people are sending more newsletters than ever
For most regular emails and newsletters I would agree. Those who truly care to know which HTML and css tags are available in email client are sending some for of ad.
Say you’re a webshop and a customer has signed up for you “newsletter” then you kinda need HTML emails to show your advertised product directly in an email client.
Say you’re a webshop and a customer has signed up for you “newsletter” then you kinda need HTML emails to show your advertised product directly in an email client.
Wouldn't that end up being a variation of https://useplaintext.email/ ?
HTML e-mail fill an important function. If it's html, it's a promotion and it gets trashed...
Html emails are as selfish and disrespectful like sneezing in other people's faces.
For the sake of presenting marketing (Logos). Disgusting. Wear a mask, write text.
For the sake of presenting marketing (Logos). Disgusting. Wear a mask, write text.
I mean, how are you going to use rich text otherwise?
Homer didn't need rich text to write the Trojan War. Neither did Shakespeare, nor Ovid for their writing. My emails are way less ambitioned and are fine written in poor text.
Nobody needs rich text.
But, almost everyone does? Would you prefer all web articles to be strictly in plain text, same colour? No font changes between text and code, no colors for quotations, no indented multilevel bullet points? Basically, nothing that markdown can do. In your opinion, those things don’t improve ease of reading, right? What about syntax highlight in code - nobody needs that either, am I getting it right?
Not in emails, you got that right.
And how are emails any different from web articles? Both contain structured thoughts represented as structured text, both often contain code and quotations, lists and so on. Why special treatment?
> And how are emails any different from web articles?
Totally different. Try for one week to substitute every sent/received email with web articles instead.
It's like a cake and an elephant not being essentially the same, just because they're both made of atoms.
Totally different. Try for one week to substitute every sent/received email with web articles instead.
It's like a cake and an elephant not being essentially the same, just because they're both made of atoms.
I also prefer plain text email. HTML email is no good, I think. However, you can use a multipart message with a plain part if wanted; Heirloom-mailx and other plain text email clients will then display the plain text part in that case.
You could specify "Content-type: text/markdown" if you want Markdown (although I don't know which email clients will understand that), although I think that plain text is OK.
I also dislike email newsletters or email discussion lists; either way, I would prefer NNTP.
You could specify "Content-type: text/markdown" if you want Markdown (although I don't know which email clients will understand that), although I think that plain text is OK.
I also dislike email newsletters or email discussion lists; either way, I would prefer NNTP.
At first glance I have no idea what this website does. At second glance I still don't.
It checks whether an email client supports and HTML or CSS feature for rendering.
Oh I wish I'd heard of this 2 years ago, would have saved me a lot of trial and error.
Email is not a webpage. Keep your web skills for the web, please.
[deleted]
Get KMail on the list!
not enough users.
well yeah, without builtin telemetry and government-grade spying, you can't tell how many users it has, fair
Edit: i realize this comes off as snarky, sorry. It's meant as a joke. It's reasonable to say that its likely not popular enough.
Edit: i realize this comes off as snarky, sorry. It's meant as a joke. It's reasonable to say that its likely not popular enough.
Apologies, just someone who recently had a customer try to convince me I should rewrite my FPGA code to handle his one or two off product (but very expensive) product for free :) so I understand why developers can't target every user haha.
great tool for emailgeeks!
This is actually a great tool to find vulnerabilities in various webmail clients such as ProtonMail and Hey, just compare the HTML or CSS features they do not yet filter compared to Gmail, then do a search for "[feature] + exploit" to see how a feature could be abused, and then submit a bounty report.
For example, there are alot of good reasons that you may not want your webmail rendering SVG images (mXSS, appcache poisoning) or allowing CSS variables or imports.
And I'm pretty sure the list supported by Gmail could also be narrowed down further. There are some fantastic bounties lurking in here, just waiting to be discovered.