4 ms·

There are good reasons to reject a lot of it. You don't want JS running in an email for example. Or even some of the fancier CSS abilities.

zozbot234 5y ago
But then why have HTML email at all? You could just write in markdown.
- jiofih 5y ago
  Not a bad idea.
- nexuist 5y ago
  Why have HTML email in the first place? No other messaging client lets you send entire HTML documents as messages. Just send me some words and a link to click on in a proper browser. The fact that HTML email is so bloated and a nightmare to eyeballs eveywhere is (IMO) a huge reason why conversations (even professional ones) shifted over to Slack, SMS, WhatsApp, FB Messenger, etc. I want a place to talk to people, not to shitty template engines. But if you're going to automate my conversation, use words, not posters.
  - SilverRed 5y ago
    You're comment made me think about why we actually use slack/IM when email is just as capable and I think the answer is that I can have notifications turned on for IM and I can't do that for email. Which means I respond much slower to email. IM is one of the last places on the internet not filled with automated crap, advertisers and spam. And to be fair, some of that automated crap I actually want and browse through at a later time but IM explicitly separates real time messages and newsletters.
    - tofukid 5y ago
      Email supports instant notifications, via your provider’s app or IMAP IDLE. I use Fastmail and get push notifications for email the instant it is received.
      - SilverRed 5y ago
        The point is if I turned on instant notifications I would go insane because they would never stop. I receive lots of emails and a lot of them are not very important or at least not urgent. While every IM I receive is something I at least want to glance at now.
        selfhoster11 5y ago
        That point, frankly, applies to some Slack workspaces too. Some of them just have too many notifications to keep track of.
        tofukid 5y ago
        Email notifications are flexible. I can choose to receive notifications only from contacts, search terms, or specific people.
- m0dest 5y ago
  I'm intrigued by that idea. Markdown or Markdown-like subsets have proven to be sufficient for communication in a variety of media (Slack, Wikipedia, forum comments, GitHub issues/comments, etc.) Email clients are a bit of an oligopoly, so execution would depend on which player(s) are involved. Most of these initiatives would need an "everyone but Outlook" coalition to succeed. A few thoughts on implementation: - Multipart MIME is still a big part of HTML mail, so it would make sense to piggypack on that support. Instead of adding a new MIME attachment for Markdown, it would make sense to extend the existing support for text/plain renditions and find some way to signal that it's Markdown. (e.g. text/plain; charset=UTF-8; variant=MarkdownMail) - For mail clients that aren't Markdown-aware, it would be important to produce an HTML-rendered variant with a reasonable style sheet. - A Markdown-first mail client would either need to limit formatting to Markdown or soft-block access to non-Markdown formatting. ("Custom text colors will not be visible on some devices and may be lost when replying. Continue?") - When viewing a Markdown-enabled message, a Markdown-first mail client would render the text/plain variant in its preferred style sheet, not the HTML-rendered variant. - When replying to a Markdown-enabled message, a Markdown-first mail client would use the text/plain variant as the source of truth for quoted replies, not the HTML-rendered variant. A few tricky areas: - Mail clients would need to agree on a Markdown dialect, especially for extensions like tables. - Markdown isn't very incompatible with quoting. There would need to be a solution for inline quoting. - For everyone's sanity, it would seem important to agree on a delimiter to separate prior messages and their headers. - To not be worse than HTML mail, we'd really need a way to signal that a paragraph is part of a mail signature so that it can be rendered in a subtle way. As much as we might wish that mail signatures would just go away, they will continue to be used, and rendering them as standard paragraph text just makes them more distracting.
whakim 5y ago
By "I wish that emails could just work like everything else on the web" I meant modern web HTML/CSS - I was replying to the GP - not the full set of browser capabilities such as Javascript. I suppose it's possible you'd also want to exclude certain CSS abilities, but at that point you're now diverging from the web CSS spec which isn't ideal either.
- fomine3 5y ago
  Web standard is continuously evolving but email don't need most of them. I think whitelist approach is better than blacklist for email.
  - whakim 5y ago
    Yes, but then who maintains the whitelist? What's to stop individual email providers from deciding they do/don't like certain standards? I agree that email doesn't need much of the CSS spec, but nor do the vast majority of web sites and yet we don't like it when browsers aren't standards-compliant...
    - fomine3 5y ago
      HTML/CSS is designed to be safe for web by browser vendors and working groups. Unused HTML/CSS feature is fine as long as it's not vulnerable, but blacklist for email is problem because new feature is not designed to be safe for email. Theoretically email client vendor can host working group like WHATWG to define standard by picking subset from web HTML/CSS. I don't know why it's not happened.
      - whakim 5y ago
        Can you share some CSS vulnerabilities that would work in email but not in a browser? I can certainly think of CSS vulnerabilities that would not work in email because email can't execute javascript, but can't come up with the reverse off the top of my head. Genuinely curious here.
derefr 5y ago
Sounds like you’re talking about the subset of HTML+CSS used in ePub. Come to think, ebooks and emails have pretty similar “richness” needs.
- craig131 5y ago
  That's a great idea, just use the ePub standard. Never made the connection between ebook formatting and email formatting before, nice.
  - shakna 5y ago
    Most ePub readers are intentionally not compliant with the standard, because the standard allows way too much. Including, for example, arbitrary execution.
- dragonwriter 5y ago
  > Sounds like you’re talking about the subset of HTML+CSS used in ePub. EPUB3 supports JS.
  - derefr 5y ago
    EPUB3 is a half-baked standard that nothing actually fully supports. The JavaScript parts especially—most e-readers don’t ever plan on adding JS support, even if they nominally support EPUB3.

zozbot234 5y ago

But then why have HTML email at all? You could just write in markdown.

jiofih 5y ago
Not a bad idea.
nexuist 5y ago
Why have HTML email in the first place? No other messaging client lets you send entire HTML documents as messages. Just send me some words and a link to click on in a proper browser. The fact that HTML email is so bloated and a nightmare to eyeballs eveywhere is (IMO) a huge reason why conversations (even professional ones) shifted over to Slack, SMS, WhatsApp, FB Messenger, etc. I want a place to talk to people, not to shitty template engines. But if you're going to automate my conversation, use words, not posters.
- SilverRed 5y ago
  You're comment made me think about why we actually use slack/IM when email is just as capable and I think the answer is that I can have notifications turned on for IM and I can't do that for email. Which means I respond much slower to email. IM is one of the last places on the internet not filled with automated crap, advertisers and spam. And to be fair, some of that automated crap I actually want and browse through at a later time but IM explicitly separates real time messages and newsletters.
  - tofukid 5y ago
    Email supports instant notifications, via your provider’s app or IMAP IDLE. I use Fastmail and get push notifications for email the instant it is received.
    - SilverRed 5y ago
      The point is if I turned on instant notifications I would go insane because they would never stop. I receive lots of emails and a lot of them are not very important or at least not urgent. While every IM I receive is something I at least want to glance at now.
      - selfhoster11 5y ago
        That point, frankly, applies to some Slack workspaces too. Some of them just have too many notifications to keep track of.
      - tofukid 5y ago
        Email notifications are flexible. I can choose to receive notifications only from contacts, search terms, or specific people.
m0dest 5y ago
I'm intrigued by that idea. Markdown or Markdown-like subsets have proven to be sufficient for communication in a variety of media (Slack, Wikipedia, forum comments, GitHub issues/comments, etc.) Email clients are a bit of an oligopoly, so execution would depend on which player(s) are involved. Most of these initiatives would need an "everyone but Outlook" coalition to succeed. A few thoughts on implementation: - Multipart MIME is still a big part of HTML mail, so it would make sense to piggypack on that support. Instead of adding a new MIME attachment for Markdown, it would make sense to extend the existing support for text/plain renditions and find some way to signal that it's Markdown. (e.g. text/plain; charset=UTF-8; variant=MarkdownMail) - For mail clients that aren't Markdown-aware, it would be important to produce an HTML-rendered variant with a reasonable style sheet. - A Markdown-first mail client would either need to limit formatting to Markdown or soft-block access to non-Markdown formatting. ("Custom text colors will not be visible on some devices and may be lost when replying. Continue?") - When viewing a Markdown-enabled message, a Markdown-first mail client would render the text/plain variant in its preferred style sheet, not the HTML-rendered variant. - When replying to a Markdown-enabled message, a Markdown-first mail client would use the text/plain variant as the source of truth for quoted replies, not the HTML-rendered variant. A few tricky areas: - Mail clients would need to agree on a Markdown dialect, especially for extensions like tables. - Markdown isn't very incompatible with quoting. There would need to be a solution for inline quoting. - For everyone's sanity, it would seem important to agree on a delimiter to separate prior messages and their headers. - To not be worse than HTML mail, we'd really need a way to signal that a paragraph is part of a mail signature so that it can be rendered in a subtle way. As much as we might wish that mail signatures would just go away, they will continue to be used, and rendering them as standard paragraph text just makes them more distracting.

whakim 5y ago

By "I wish that emails could just work like everything else on the web" I meant modern web HTML/CSS - I was replying to the GP - not the full set of browser capabilities such as Javascript. I suppose it's possible you'd also want to exclude certain CSS abilities, but at that point you're now diverging from the web CSS spec which isn't ideal either.

fomine3 5y ago
Web standard is continuously evolving but email don't need most of them. I think whitelist approach is better than blacklist for email.
- whakim 5y ago
  Yes, but then who maintains the whitelist? What's to stop individual email providers from deciding they do/don't like certain standards? I agree that email doesn't need much of the CSS spec, but nor do the vast majority of web sites and yet we don't like it when browsers aren't standards-compliant...
  - fomine3 5y ago
    HTML/CSS is designed to be safe for web by browser vendors and working groups. Unused HTML/CSS feature is fine as long as it's not vulnerable, but blacklist for email is problem because new feature is not designed to be safe for email. Theoretically email client vendor can host working group like WHATWG to define standard by picking subset from web HTML/CSS. I don't know why it's not happened.
    - whakim 5y ago
      Can you share some CSS vulnerabilities that would work in email but not in a browser? I can certainly think of CSS vulnerabilities that would not work in email because email can't execute javascript, but can't come up with the reverse off the top of my head. Genuinely curious here.

derefr 5y ago

Sounds like you’re talking about the subset of HTML+CSS used in ePub. Come to think, ebooks and emails have pretty similar “richness” needs.

craig131 5y ago
That's a great idea, just use the ePub standard. Never made the connection between ebook formatting and email formatting before, nice.
- shakna 5y ago
  Most ePub readers are intentionally not compliant with the standard, because the standard allows way too much. Including, for example, arbitrary execution.
dragonwriter 5y ago
> Sounds like you’re talking about the subset of HTML+CSS used in ePub. EPUB3 supports JS.
- derefr 5y ago
  EPUB3 is a half-baked standard that nothing actually fully supports. The JavaScript parts especially—most e-readers don’t ever plan on adding JS support, even if they nominally support EPUB3.