Comment by jcranmer | Hacker News Reader

Comment by jcranmer | Hacker News Reader

> A standardized HTML specification for email; complete with a test suite for conformance. Or, maybe we just declare a version of the HTML5 spec to be officially binding and that’s the end of it.

keels over in laughter

Oh, there's been quite a few attempts at at standardizing HTML rules for email. I was even in one of them, which petered out very quickly.

Functionally speaking, the problem is you have three groups of people with HTML email (well, four groups, if you include the people who wish it died off). You have the marketing folks, who want HTML email to work essentially exactly like regular webpages so they can do all their normal design stuff and get it to work. You have the MUA implementers (particularly webmail), who need to aggressively sandbox and sanitize the HTML because to do otherwise is to risk security leaks. And you have Microsoft, who needs to keep visual compatibility with Word HTML because their userbase would flip out if they broke stuff. These groups want different stuff from HTML, and they're not going to do a good job of reconciling their viewpoints with one another.

Microsoft has done more damage to HTML email than everyone else put together. They’ve single-handedly held it back by at least ten years (maybe fifteen), and created tens or hundreds of thousands of jobs.

In Outlook 97, they used the MSO renderer (Microsoft Word) for editing and presentation. It has an incomplete and buggy implementation of HTML 3.2.

In Outlook 2000–2003, they did the obvious sensible thing: ditch that, and use MSHTML (Internet Explorer).

In Outlook 2007, they switched back to MSO, for reasons that never made a skerrick of sense to me (their explanation was vague nonsense that included the word “security”, but the articles that discussed it vanished from the web long ago so I can’t point you to any). I believe they still use the MSO renderer to this day. Windows Mail still embedded MSO. I think that the new Outlook client they released last yearish? was still using MSO, though I’ve heard claims to the contrary as well.

The MSO component has had, I think, approximately two changes in the last 28 years, one of which was supporting high DPI (… which it does imperfectly) and the other I forget.

Since one of the major email clients is still using a dodgy implementation of 1997 web standards, what incentive have other providers had for supporting newer stuff?

We’re slowly getting places, but when you contrast it with the web’s pace, in both backend and frontend (e.g. HTTPS deployment, and new CSS/HTML/JS features)—well, it’s very obviously a completely different environment.

They were embedding IE — I imagine their security concerns were well-founded. But even gmail has crappy html support, and that runs in a friggin’ browser!

MSO probably had security problems at least as large.

And if there were security issues, they needed to fix them for IE’s sake already!

I don’t remember the details of what they wrote, and wasn’t able to find it even five years ago, but I do remember that the reasons claimed just made no sense.

> MSO probably had security problems at least as large.

Down in the parser and such, no doubt about it. But it would have also lacked much of the attack surface of IE, such as, oh, ActiveX. Granted that specific example would be easy enough to disable, but that's just one mine in the whole field. They definitely should have wrestled IE into shape, but the IE team clearly wasn't taking marching orders from the Office team. Organizational dysfunction manifested in sofware.

Fifth group here: HTML mail should never have been implemented. Better, never thought of in the first place.

1. Yeah the marketing folks would hate this but we need to use a subset of HTML.

2. Ok so these are the people who are going to want to help us and they run the largest email servers at the moment

3. I think MS products already have web views in them (either edge or old edge), if we had a change over like MX 2 maybe that would be an acceptable trade off to break the old.

We don't need a subset of HTML. Actually, we need Markdown emails. You can format stuff that needs structure, but not abusively so (no blinking marquee banners in eyesore colors), it is sufficiently compatible to plaintext that you don't even need the text alternative mime object. It is also more compact than HTML.

And before somebody says "won't fly", all those fancy new "will replace email someday" messengers use markdown or some parts of it's formatting.

You know what? We had that. Markdown was modelled after it.

I would also state that Markdown itself is completely unsuitable for the purpose. You’d need to design something new which might look very similar to Markdown, but which would have basically no shared behaviour with even CommonMark as regards parsing, since you don’t want HTML to be a thing. Markdown itself is seriously compromised by its HTML basis.

I can’t actually think of a single comparatively-mainstream messenger that uses even a variant of Markdown; rather, they use their own lightweight markup languages <https://en.wikipedia.org/wiki/Lightweight_markup_language> that are very clearly incompatible with Markdown. (It’s also often a frontend editing feature that gets turned into something like HTML after that.)

text/enriched has been around for decades, and supports basic font styling (bold/italic/underline, color, font face, font size) and that's basically it.

Actually, text/markdown exists as well. However, the definition of markdown syntax is, um, less than precise: https://daringfireball.net/projects/markdown/syntax (the text/markdown RFC literally has a parameter to indicate which flavor you meant by markdown!). And it incorporates HTML too, FWIW--legal HTML fragments are legal markdown as well. Honestly, markdown's million variants makes the HTML support landscape look uniform.

Reply on news.ycombinator.com