4 ms·

> IMO, HTML was the worst thing that ever happened to email. Plain text content is the best content. Your first statement might be true (it's debatable). Your

> IMO, HTML was the worst thing that ever happened to email. Plain text content is the best content. Your first statement might be true (it's debatable). Your second is definitely false. Lets assume that HTML really was the worst thing that ever happened to email. Plain text content for email is still not the best content. People want to: 1. Click on a link in the email, not fumble with copy and paste on their phone. 2. See decently formatted paragraphs and content with bold, italics and different font sizes for headings and paragraphs, not a wall of text. 3. See images in the email itself, not have to once again fumble around with copy and paste. 4. Correctly formatted bullet points, including sub-lists. For all of the above, some sort of format is required. If we exclude HTML as a possibility, you're still going to have to need a format of some type, because the wall-o-text format is not a good UI.

makapuf 3y ago
A subset of markdown (since you can use html in markdown) might be a good candidate.
- prmoustache 3y ago
  I would have favored gemtext to avoid the temptation of re-adding html support to a dumbed down markdown flavor.
ivanjermakov 3y ago
Regarding 1. it's up to the client to parse and highlight links in plain text.
- lelanthran 3y ago
  > Regarding 1. it's up to the client to parse and highlight links in plain text. If the client is interpreting the content and then displaying its interpretation to the user, then it's not plain text anymore, is it? It's a format; in this case it's a poorly-specified, ad-hoc format and broken format[1] that is worse than simply having a reduced ad-hoc HTML format. Just like HTML is "plain text" which is interpreted by the client and that interpretation is displayed to the user. [1] For example, what if the sender types in `You should go to http://ww.example.com http://ww.example.com, where "example" must be replaced with your company name`? Suddenly `www.example.com` has an unintended DDoS!
  - sanitycheck 3y ago
    I imagine example.com is either set up to be robust enough to withstand that, or they don't care if it goes down: https://www.iana.org/help/example-domains https://www.iana.org/help/example-domains Oh interesting, I pasted a URL in plain text and a bit of code in HN turned it into a link you can click on. I think it's totally fine for email clients to do that too. The only thing I find redeeming about HTML email is the ability to have inline images so when I'm illustrating some sort of process to somebody I can do it more clearly. Without those, I'd create and send a proper document (I don't object to attachments), or publish the information on a wiki/blog/etc - but perhaps a those would be overall better approaches than a 'rich' email.
  - ivanjermakov 3y ago
    Fair, but url syntax is strictly defined in RFC 3986: https://datatracker.ietf.org/doc/html/rfc3986 https://datatracker.ietf.org/doc/html/rfc3986
    - lelanthran 3y ago
      What does that have to do with someone typing 'http://example.com http://example.com' with the intention that that is not turned into a link?
  - CRConrad 3y ago
    > If the client is interpreting the content and then displaying its interpretation to the user, then it's not plain text anymore, is it? Yes it is. > It's a format Yes, plain text is a format. The best format. > in this case it's a poorly-specified, ad-hoc format and broken format[1] that is worse than simply having a reduced ad-hoc HTML format. Well sure, plain text sucks at being HTML. That's because it isn't HTML; it's plain text. Plain text is not "poorly-specified, ad-hoc and broken" as plain text; only as HTML. The solution is not to use it as HTML. > For example, what if the sender types in `You should go to http://ww.example.com http://ww.example.com, where "example" must be replaced with your company name`? Suddenly `www.example.com` has an unintended DDoS! Ah, so that doesn't happen if the sender types in the wrong thing in HTML...?
ktosobcy 3y ago
1. all links are click-able at this point; what's more plain-text would force to provide just a link without all the tracking garbage 2. you can have paragraphs and headings... it's just a matter of structure - using html you can write a wall of text just fine 3. not sure if needed, besides you can attach images to plain text (though not inlining) or click-able links to external sources (at exact place) 4. still - easily do-able; it's a matter of particular editor tracking lists - for markdown editors it works just fine and in the end you virtually have a "plain text bullet list"... magic. The most contagious/problematic issue is (3) and inlining - as I said, it's possible to attach anything but the location is lost. Probably something simple like anchor (again, markdown linking comes to mind) to indicate placement would be just fine... (I loath html mails with passion…)
- lelanthran 3y ago
  > 1. all links are click-able at this point; what's more plain-text would force to provide just a link without all the tracking garbage 2. you can have paragraphs and headings... it's just a matter of structure - using html you can write a wall of text just fine 3. not sure if needed, besides you can attach images to plain text (though not inlining) or click-able links to external sources (at exact place) 4. still - easily do-able; it's a matter of particular editor tracking lists - for markdown editors it works just fine and in the end you virtually have a "plain text bullet list"... magic. I think this comment displays the problems with plain text. I really couldn't have provided a better example. As regards the counterpoints: 1. All links are clickable Yes, and that's a bug. "http://www.example.com http://www.example.com" should not be a clickable line. More to the point, it's not plain text anymore if the user gets something that has been interpreted and then rendered by the software. 2. It's not obvious how this should be done, and how it should reflow. You yourself failed to manage this in your reply, which I consider a good argument for why plain text is a poor UI. 3. Who cares whether you need it or not. The reality is that the clear majority of people use it! 4. Once again, if we're talking about a specific format that gets rendered into something readable, then it's not plain text anymore. I'm arguing against the GPs assertion that plain text is the best format, not that markdown is insufficient.
  - 3y ago

makapuf 3y ago

A subset of markdown (since you can use html in markdown) might be a good candidate.

prmoustache 3y ago
I would have favored gemtext to avoid the temptation of re-adding html support to a dumbed down markdown flavor.

ivanjermakov 3y ago

Regarding 1. it's up to the client to parse and highlight links in plain text.

lelanthran 3y ago
> Regarding 1. it's up to the client to parse and highlight links in plain text. If the client is interpreting the content and then displaying its interpretation to the user, then it's not plain text anymore, is it? It's a format; in this case it's a poorly-specified, ad-hoc format and broken format[1] that is worse than simply having a reduced ad-hoc HTML format. Just like HTML is "plain text" which is interpreted by the client and that interpretation is displayed to the user. [1] For example, what if the sender types in `You should go to http://ww.example.com http://ww.example.com, where "example" must be replaced with your company name`? Suddenly `www.example.com` has an unintended DDoS!
- sanitycheck 3y ago
  I imagine example.com is either set up to be robust enough to withstand that, or they don't care if it goes down: https://www.iana.org/help/example-domains https://www.iana.org/help/example-domains Oh interesting, I pasted a URL in plain text and a bit of code in HN turned it into a link you can click on. I think it's totally fine for email clients to do that too. The only thing I find redeeming about HTML email is the ability to have inline images so when I'm illustrating some sort of process to somebody I can do it more clearly. Without those, I'd create and send a proper document (I don't object to attachments), or publish the information on a wiki/blog/etc - but perhaps a those would be overall better approaches than a 'rich' email.
- ivanjermakov 3y ago
  Fair, but url syntax is strictly defined in RFC 3986: https://datatracker.ietf.org/doc/html/rfc3986 https://datatracker.ietf.org/doc/html/rfc3986
  - lelanthran 3y ago
    What does that have to do with someone typing 'http://example.com http://example.com' with the intention that that is not turned into a link?
- CRConrad 3y ago
  > If the client is interpreting the content and then displaying its interpretation to the user, then it's not plain text anymore, is it? Yes it is. > It's a format Yes, plain text is a format. The best format. > in this case it's a poorly-specified, ad-hoc format and broken format[1] that is worse than simply having a reduced ad-hoc HTML format. Well sure, plain text sucks at being HTML. That's because it isn't HTML; it's plain text. Plain text is not "poorly-specified, ad-hoc and broken" as plain text; only as HTML. The solution is not to use it as HTML. > For example, what if the sender types in `You should go to http://ww.example.com http://ww.example.com, where "example" must be replaced with your company name`? Suddenly `www.example.com` has an unintended DDoS! Ah, so that doesn't happen if the sender types in the wrong thing in HTML...?

ktosobcy 3y ago

1. all links are click-able at this point; what's more plain-text would force to provide just a link without all the tracking garbage 2. you can have paragraphs and headings... it's just a matter of structure - using html you can write a wall of text just fine 3. not sure if needed, besides you can attach images to plain text (though not inlining) or click-able links to external sources (at exact place) 4. still - easily do-able; it's a matter of particular editor tracking lists - for markdown editors it works just fine and in the end you virtually have a "plain text bullet list"... magic. The most contagious/problematic issue is (3) and inlining - as I said, it's possible to attach anything but the location is lost. Probably something simple like anchor (again, markdown linking comes to mind) to indicate placement would be just fine... (I loath html mails with passion…)

lelanthran 3y ago
> 1. all links are click-able at this point; what's more plain-text would force to provide just a link without all the tracking garbage 2. you can have paragraphs and headings... it's just a matter of structure - using html you can write a wall of text just fine 3. not sure if needed, besides you can attach images to plain text (though not inlining) or click-able links to external sources (at exact place) 4. still - easily do-able; it's a matter of particular editor tracking lists - for markdown editors it works just fine and in the end you virtually have a "plain text bullet list"... magic. I think this comment displays the problems with plain text. I really couldn't have provided a better example. As regards the counterpoints: 1. All links are clickable Yes, and that's a bug. "http://www.example.com http://www.example.com" should not be a clickable line. More to the point, it's not plain text anymore if the user gets something that has been interpreted and then rendered by the software. 2. It's not obvious how this should be done, and how it should reflow. You yourself failed to manage this in your reply, which I consider a good argument for why plain text is a poor UI. 3. Who cares whether you need it or not. The reality is that the clear majority of people use it! 4. Once again, if we're talking about a specific format that gets rendered into something readable, then it's not plain text anymore. I'm arguing against the GPs assertion that plain text is the best format, not that markdown is insufficient.
- 3y ago