Hacker News Reader

Comment by ognarb | Hacker News Reader

I long argued that we should use markdown (without the inline HTML) or a similar simple text markup instead of HTML for rich text in emails. This would makes it easy for emails clients to decide about either showing the text as rich text or just plain text, while supporting most of the formatting that a normal user might need: bold, italic, quotes, inline images, code blocks, headers, ...

Sure it wouldn't be good for marketing emails with the super advanced HTML but I don't think anyone should care about this use-case.

View on HN

Something similar exists as text/enriched defined in RFC 1896. Apple Mail, among others, supports it.

https://en.wikipedia.org/wiki/Enriched_text

https://www.rfc-editor.org/rfc/rfc1896.html

> https://en.wikipedia.org/wiki/Enriched_text

Ironically references an article called "Why HTML is Inappropriate for E-Mail" (http://www.avernus.com/~gadams/essays/20020418-html-mail.htm...) posted way back in 2002 apparently.

We're just walking around in circles after all...

This goes back to 1998 at the very least: https://en.wikipedia.org/wiki/ASCII_ribbon_campaign

It was clear from the start that using HTML in email was a bad idea.

This sort of dogmatic rejection of HTML ended up being the bigger problem. If instead futilely fighting against HTML email the community would have just embraced the idea, we could have a sensible spec for email (instead of just ad-hoc whatever Outlook does) and email could have had a chance to prevent its fading relevancy.

But no, we had to fight the great evil of rich text which left vendors, MS in the forefront, to their own means to fulfill the strong and justified user demand, with predictable outcome.

RFC 1896 defined a sensible alternative in 1996. I agree that it should have received more support, although at least a range of Unix MUAs and Apple Mail did and do support it.

Many markdown parsers allow inline html. In some languages, it’s most of them. Only a few let you turn it off. So stupid.

For better or worse, inline HTML was key part of original markdown spec:

> For any markup that is not covered by Markdown’s syntax, you simply use HTML itself. There’s no need to preface it or delimit it to indicate that you’re switching from Markdown to HTML; you just use the tags.

> If you want, you can even use HTML tags instead of Markdown formatting; e.g. if you’d prefer to use HTML <a> or <img> tags instead of Markdown’s link or image syntax, go right ahead.

Markdown was not really intended as standalone markup format, instead it was more just a tool for authoring HTML

> Markdown’s syntax is intended for one purpose: to be used as a format for writing for the web.

Well, the markdown specification allows inline HTML, so that's to be expected. But it's true if you're taking user input as markdown and display it as rendered HTML, you need to think very carefully about escaping and sanitization.

Given that the Lynx browser (HTML in a text terminal) continues to function reasonably well, why is there any need for a different markup language?

It helps for keeping the feature set limited. With HTML, the incentive to use a full-blown implementation is just too strong, and the risk of inconsistent implementations and deliberate or accidental extensions too high.

You could also in theory just restrict which HTML elements can be used. You’d need to do that anyway for MD, especially since MD can contain HTML itself.

I’m a huge fan of MD either way ;) I’ve built entire large sites where raw content is stored in MD (along with a MD WYSIWYG) and then the MD is converted to HTML. I’ve found it’s easier and more reliable to parse MD vs HTML, unless of course you’re using a block editor or something more structured.

> You could also in theory just restrict which HTML elements can be used.

That’s not enough, because you also have to restrict what attributes they may carry (inline styles, event handlers), the type of meta tags and image formats, and so on.

But in any case, such a restricted subset was what I was already presuming in my comment.

You don't have to restrict them at all.

You just ignore them.

That's what is meant by restricting.

Well, getting enough uptake is difficult because email standards are hard to change. We still don't have support for hyperlinking emails, though I tried to fix that recently:

https://pastebin.com/kHQs50xm

The mid: scheme (see https://datatracker.ietf.org/doc/html/rfc2111) can theoretically do that and has been around since, uh, 1997.

Yep, and even with it being possible, no one's bothered to make it usable for email hyperlinks, hence the problem. The (attempt at an) RFC I linked avoids depending on the other side tracking the MessageID, assuming only things they would want to store.

Message-ID is something already stored in your email database, because it's necessary for a lot of stuff (in particular, threading conversations correctly). I'd be shocked if any email store didn't support querying by message-ID. Querying by body is a lot harder, since you need full-text support in the body. It's not the difficulty of implementing mid that's blocking support in clients.

Color and Size are basic, useful aspects of writing.

Reply on news.ycombinator.com