3 ms·

Forsaking HTML doesn't imply embracing command line. In my experience, most mails don't actually use any styling beyond the automatic blockquote for the endles

Forsaking HTML doesn't imply embracing command line. In my experience, most mails don't actually use any styling beyond the automatic blockquote for the endless quote chains that mail clients automatically add. So people are wasting storage and transfer for something they don't really use. When I see a mail which could actually use some styling, it's usually something involving maths and HTML is not suitable for that case. People usually send LaTeX snippets in plain text in this case. And while I'm at it, the endless quote chains are another thing which has no reason for existing. Each mail in a thread steadily grows in size, because mail clients "conveniently" always quote everything and put the text cursor above it so that the user doesn't stop for a moment to look at the size of what they're sending and consider the absurdity of the situation, when their client is perfectly capable of reconstructing the whole thread without copying all mails in each message. Quoting should be opt-in on a case-by-case basis. As they function in the wild today, the quotes are just useless garbage attached to everything.

fragmede 4y ago
HTML vs plain text is a distraction; it's not the 1970's anymore and saving a byte or two here and there just isn't the computing world we're living in. Not when images, video, or audio files regularly get attached to email. Quote chains are why it's both email and email clients that need to improve. Without consensus on what's "right", we're left with poor solutions with poor UX, and implemented in a fragmented way, because all clients need to agree. What's more, how do you loop someone into a conversation they weren't previously a part of, if you don't have the history of the thread in each mail? This is something Slack gets right, and because they control the client as well, they can unilaterally make changes that support their view of how message history works. The strength of email is in its decentralization but here, it becomes a shortcoming.
- yakubin 4y ago
  > HTML vs plain text is a distraction; it's not the 1970's anymore and saving a byte or two here and there just isn't the computing world we're living in. Not when images, video, or audio files regularly get attached to email. It's not about HTML vs plain text. It's about HTML vs a way to style text which is actually useful to the users. HTML is so bad for this purpose, in practice 99% of HTML mails don't use any tags in their proper content and mails which could use some styling to make them more readable are using plain text, because HTML is of no help to them. My remark about overhead was actually about the quotes, whose sizes grow linearly as threads get longer (and the threads grow quadratically instead of linearly), not about HTML. You don't pay for tags you do not use (almost). The only rich HTML mails (as opposed to plain text HTML mails) I get are marketing mails, which want to track me and "stand out from the crowd", neither of which I have an interest in, and HR mails. > What's more, how do you loop someone into a conversation they weren't previously a part of, if you don't have the history of the thread in each mail? This is something Slack gets right Slack doesn't get it right. When you join a conversation, you always see the whole history. But in practice people conduct conversations according to the assumption of who is taking part in them at a given moment. They can't predict the future and that someone will add another person to the conversation, and now this person will see everything they wrote. There is no way to add them to the conversation with a context of "the last n messages" e.g. In an ideal mail client you would select which messages from the thread you want to share with the newly-added conversation participant.
Wowfunhappy 4y ago
> Forsaking HTML doesn't imply embracing command line. To be clear, I agree, but it was the only reason I could see in GP for why HTML was annoying. (Not to say GP doesn't have a right to be annoyed, I just think that particular reason is unique.)

fragmede 4y ago

HTML vs plain text is a distraction; it's not the 1970's anymore and saving a byte or two here and there just isn't the computing world we're living in. Not when images, video, or audio files regularly get attached to email. Quote chains are why it's both email and email clients that need to improve. Without consensus on what's "right", we're left with poor solutions with poor UX, and implemented in a fragmented way, because all clients need to agree. What's more, how do you loop someone into a conversation they weren't previously a part of, if you don't have the history of the thread in each mail? This is something Slack gets right, and because they control the client as well, they can unilaterally make changes that support their view of how message history works. The strength of email is in its decentralization but here, it becomes a shortcoming.

yakubin 4y ago
> HTML vs plain text is a distraction; it's not the 1970's anymore and saving a byte or two here and there just isn't the computing world we're living in. Not when images, video, or audio files regularly get attached to email. It's not about HTML vs plain text. It's about HTML vs a way to style text which is actually useful to the users. HTML is so bad for this purpose, in practice 99% of HTML mails don't use any tags in their proper content and mails which could use some styling to make them more readable are using plain text, because HTML is of no help to them. My remark about overhead was actually about the quotes, whose sizes grow linearly as threads get longer (and the threads grow quadratically instead of linearly), not about HTML. You don't pay for tags you do not use (almost). The only rich HTML mails (as opposed to plain text HTML mails) I get are marketing mails, which want to track me and "stand out from the crowd", neither of which I have an interest in, and HR mails. > What's more, how do you loop someone into a conversation they weren't previously a part of, if you don't have the history of the thread in each mail? This is something Slack gets right Slack doesn't get it right. When you join a conversation, you always see the whole history. But in practice people conduct conversations according to the assumption of who is taking part in them at a given moment. They can't predict the future and that someone will add another person to the conversation, and now this person will see everything they wrote. There is no way to add them to the conversation with a context of "the last n messages" e.g. In an ideal mail client you would select which messages from the thread you want to share with the newly-added conversation participant.

Wowfunhappy 4y ago

> Forsaking HTML doesn't imply embracing command line. To be clear, I agree, but it was the only reason I could see in GP for why HTML was annoying. (Not to say GP doesn't have a right to be annoyed, I just think that particular reason is unique.)