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.
> 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.
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.
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 ;(
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.
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.
10 comments
[ 4.5 ms ] story [ 29.9 ms ] threadAs 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.
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.
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.
Though I'm not aware of a modern MUA employing SGML ;(