The text/enriched MIME Content-type (1996) | Hacker News Reader

The text/enriched MIME Content-type (1996)

rfc-editor.org

As someone who works on an email system, it's a bit of a shame that this didn't win over HTML at least for email between humans. HTML is a bit of nightmare to sanitize. It's also expensive to layout compared to something like text/enriched which wouldn't need a full WebView on mobile - you'd be able to easily layout using native view widgets. Especially when you consider HTML in emails is stuck on a mostly old school table based layout system for highly styled emails, and a lot of these emails are not responsive.

Some MUAs still support it for display, but no longer for creation. Which rather makes sense as old emails can hang around on systems for years.

As I recall Apple Mail.app can still decode them, as can mutt.

Mutt allows one to compose such, but without any specific help - one has to write the markup raw, then change the MIME type before sending.

> As someone who works on an email system, it's a bit of a shame that this didn't win over HTML

But, I mean, it explicitly said it expected HTML to win, and even included code to “upgrade” text/enriched to HTML 2.0 as a forward-compatibility measure given that eventuality.

>a bit of nightmare to sanitize

The fact that mail has to be sanitized at all is already a nightmare, and a perfect example of where inappropriate reuse of existing standard can lead to.

I remember seeing this and liking it. It is too bad that it did not, apparently, catch on. I seem to recall suggesting to the RFC authors that the RFC itself should be available in text/enriched.

Emacs has a mode for this: https://www.gnu.org/software/emacs/manual/html_node/emacs/En...

Refusing to use attributes in this kind of *ML and using <param> instead makes this a mess to parse safely. I imagine this will be read as HTML and the params will show up in the document oddly.

Always wondering if there's a standard format for the thing in emails that uses underscore, slashes, asterisks for underline, italics, bold and less/greater than for URLs. Never found it. Always thought it would be a great addition to pandoc output formats :)

Technically, formatting rules like these can be described using SGML short references, which then serve to replace those tokens by start- and end-element tags into angle-bracket markup (SGML, XML, HTML). Works for block quotes, too, as tokens scanned for replacement can be anchored at line beginnings (can include "record start" and "record end" characters).

Though I'm not aware of a modern MUA employing SGML ;(

Markdown but with <> for URLs instead of []? It does seem like Markdown borrowed some of these ad hoc conventions for its syntax.

Reply on news.ycombinator.com