4 ms·

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

by ognarb 3y ago

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.

PaulDavisThe1st 3y ago
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?
- layer8 3y ago
  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.
  - lobsterthief 3y ago
    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.
    - layer8 3y ago
      > 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.
      - PaulDavisThe1st 3y ago
        You don't have to restrict them at all. You just ignore them.
        layer8 3y ago
        That's what is meant by restricting.
layer8 3y ago
Something similar exists as text/enriched defined in RFC 1896. Apple Mail, among others, supports it. https://en.wikipedia.org/wiki/Enriched_text https://en.wikipedia.org/wiki/Enriched_text https://www.rfc-editor.org/rfc/rfc1896.html https://www.rfc-editor.org/rfc/rfc1896.html
- diggan 3y ago
  > https://en.wikipedia.org/wiki/Enriched_text 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.html 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...
  - layer8 3y ago
    This goes back to 1998 at the very least: https://en.wikipedia.org/wiki/ASCII_ribbon_campaign https://en.wikipedia.org/wiki/ASCII_ribbon_campaign It was clear from the start that using HTML in email was a bad idea.
    - zokier 3y ago
      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.
      - layer8 3y ago
        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.
lupire 3y ago
Color and Size are basic, useful aspects of writing.
hinkley 3y ago
Many markdown parsers allow inline html. In some languages, it’s most of them. Only a few let you turn it off. So stupid.
- zokier 3y ago
  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.
- cdcarter 3y ago
  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.
SilasX 3y ago
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 https://pastebin.com/kHQs50xm
- jcranmer 3y ago
  The mid: scheme (see https://datatracker.ietf.org/doc/html/rfc2111 https://datatracker.ietf.org/doc/html/rfc2111) can theoretically do that and has been around since, uh, 1997.
  - SilasX 3y ago
    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.
    - jcranmer 3y ago
      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.

by ognarb 3y ago

PaulDavisThe1st 3y ago

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?

layer8 3y ago
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.
- lobsterthief 3y ago
  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.
  - layer8 3y ago
    > 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.
    - PaulDavisThe1st 3y ago
      You don't have to restrict them at all. You just ignore them.
      - layer8 3y ago
        That's what is meant by restricting.

layer8 3y ago

Something similar exists as text/enriched defined in RFC 1896. Apple Mail, among others, supports it. https://en.wikipedia.org/wiki/Enriched_text https://en.wikipedia.org/wiki/Enriched_text https://www.rfc-editor.org/rfc/rfc1896.html https://www.rfc-editor.org/rfc/rfc1896.html

diggan 3y ago
> https://en.wikipedia.org/wiki/Enriched_text 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.html 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...
- layer8 3y ago
  This goes back to 1998 at the very least: https://en.wikipedia.org/wiki/ASCII_ribbon_campaign https://en.wikipedia.org/wiki/ASCII_ribbon_campaign It was clear from the start that using HTML in email was a bad idea.
  - zokier 3y ago
    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.
    - layer8 3y ago
      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.

lupire 3y ago

Color and Size are basic, useful aspects of writing.

hinkley 3y ago

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

zokier 3y ago
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.
cdcarter 3y ago
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.

SilasX 3y ago

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 https://pastebin.com/kHQs50xm

jcranmer 3y ago
The mid: scheme (see https://datatracker.ietf.org/doc/html/rfc2111 https://datatracker.ietf.org/doc/html/rfc2111) can theoretically do that and has been around since, uh, 1997.
- SilasX 3y ago
  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.
  - jcranmer 3y ago
    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.