[jayofdoom]

I used this for a while. It doesn't display HTML emails just fine. It only supports a subset of stuff which -- as a geek is awesome because it protects me -- but would be hideous to give to a normal user. Literally less than half of my emails were readable.

[thephyber]

As someone with deep experience in MIME encoding/parts, HTML for emails, and email client support for different HTML/CSS/image content, this is a sinkhole.

The world will be better off when we fork HTML so there is one standard email-safe version that all modern email clients support natively. There’s entirely too much security surface area to put arbitrary HTML into emails and expect any 2 email clients to render it correctly / the same.

Email needs its “no more IE6” moment.

[fc417fc802]

> There’s entirely too much security surface area to put arbitrary HTML into emails ...

We manage it with browsers though.

Don't get me wrong, I've never liked html in emails to begin with. It's the same issue that markdown and every other rich text system has regarding where to draw the line. HN even strips most emojis (and I think that's a good thing).

[thephyber]

“We manage it”

Vapid statement.

When emojis are stripped on one website, users of that website understand it’s a product limitation.

When links work on one email client but not another, that’s a huge issue for the email sender and a lot of headache to learn/study the differences between email clients and the stack they are built on.

The difference between HTML and CSS properties supported on different email clients is WILD.[1] the rendering differences are significant, as are the man hours required to get emails to mostly look predictable on the breadth of email clients in use today.

And remember that every time there is a browser engine (or even just a fork) people have to maintain it. They need to develop features, squash bugs, patch security issues, pull from upstream, coordinate with downstream forks, etc. webmail providers are SaaS but have to have intricate and accurate understanding of every browser parse / rendering bug/permutation and a deep understanding of all of the legit HTML/CSS/JavaScript/DOM/XML/images/URLs (including weird ones like data: blobs) supported by every browser.

“we manage it” is doing an insane amount of hiding the complexity there.

[1] https://templates.mailchimp.com/resources/email-client-css-s...

[fc417fc802]

I never claimed email clients were uniform (that would obviously be incorrect). I responded to "too much security surface area" with "browsers seem to manage it". The security is clearly a solvable problem because we all use the solution every day.

In your analogy, different email clients equate to different products (ie websites). I agree that it's a headache for users. My point was that it's not an unsolvable security issue but rather an unsolvable lack of agreement about what should and shouldn't be included in a rich text representation, or if email should even use rich text at all for that matter.

[ricardobeat]

Hopefully they are not getting exquisitely crafted newsletters in space.

[yjftsjthsd-h]

Would it matter for this particular use?

[sombragris]

Are you sure? You used the the Fancy HTML Viewer plugin, which uses WebkitGTK2? I never had any problems with HTML Mail rendering in Claws. Your experience must be clearly peculiar to yourself.