5 ms·

Email does suck, at least HTML email. And that's not just because HTML was and still is the wrong markup tool for email. I'm reading most of my mail with mutt

by jcynix 4y ago

Email does suck, at least HTML email. And that's not just because HTML was and still is the wrong markup tool for email. I'm reading most of my mail with mutt on the command line and that works quite well. Until … some email with a confirmation link for something shows up. Or with the wrong MIME structure. Because these confirmation links more often than not are execessivly long, state-carrying links, which wrap around even in my 99 (or more) columns wide windows. Because lazy web designers don't use a short SHA key, which would relate to a database entry of the full data. No, they send their complete state. Oh, and did I mention those MIME emails with the wrong structure? Where the first part is the text part telling me that my MUA cannot display their fine mail? It can (easily formatted with external helpers like w3m) but I have to select the 2nd or 3rd part of their "fine" mail first by hand.

Wowfunhappy 4y ago
> Email does suck, at least HTML email. And that's not just because HTML was and still is the wrong markup tool for email. I mean, citation needed. I’m ready to consider the idea but give me a reason! 95+% of computer users will not want to use a command line.
- GrumpySloth 4y ago
  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.
- jcynix 4y ago
  In my day job I use Thunderbird on a Mac, with HTML turned off. Because too many colleagues send Office attachments. So you don't need to use a command line to turn HTML off (but neither do you need to be afraid to use it CLI ;-) Citations: "HTML Email: Whenever Possible, Turn It Off!" https://subversion.american.edu/aisaac/notes/htmlmail.htm https://subversion.american.edu/aisaac/notes/htmlmail.htm https://phishingtackle.com/articles/phishing-emails-with-html-attachments-in-2022/ https://phishingtackle.com/articles/phishing-emails-with-htm...
- aendruk 4y ago
  Markdown would better serve 95% of the email I see.
  - wahern 4y ago
    Indeed, Markdown is literally derived from the markup conventions invented for usenet and e-mail messages.
  - joshuamorton 4y ago
    The markdown spec includes the full html spec (https://daringfireball.net/projects/markdown/syntax#html https://daringfireball.net/projects/markdown/syntax#html)
  - dont__panic 4y ago
    Agreed wholeheartedly. I'd love to see email clients embrace markdown rendering (and sending) as an alternative to HTML. For stuff like links, headings, bulleted lists, tables, etc. in a single page, markdown is perfect. Emails rarely exceed the complication of a readme, and markdown works amazingly for those. Even better: it remains totally readable in its raw unrendered form. So you're not really forcing anyone else to adopt your syntax, just... nudging.
  - pabs3 4y ago
    My MUA (GNOME evolution) supports sending markdown emails.
    - aendruk 4y ago
      That’s a compelling feature. Can you have it actually send as `Content-Type: text/markdown` or does it still convert to HTML for now?
      - pabs3 4y ago
        It offers three markdown mail composition options: Markdown (text/markdown), Markdown as Plain Text (text/plain), Markdown as HTML (text/plain and text/html). Doesn't seem to be a way to have text/markdown and text/html though. It also renders incoming text/markdown emails in a HTML-like way using WebKit, rather than showing the raw markdown data.
- gpvos 4y ago
  What does the command line have to with non-HTML mail? It's perfectly feasible to have a window-based mail client that creates text mails.
- blooalien 4y ago
  95+% of computer users who mention not wanting to use or see a command line are so utterly terrified by the command line "bogeyman" that they imagine command lines appearing in places they would actually never be, or be required.
rsync 4y ago
"No, they send their complete state." Oh, so that is what is happening ? When I see these extremely long URLs I know, of course, that someone is being clueless and sloppy and I know, of course, that whatever they are embedding could be hashed or compressed to 64 (or fewer) characters ... But you are saying that what I am witnessing is the entire state of the transaction is being passed in the URL ? I guess I thought that they were passing multiple third party tracking strings all in the same URL and that different parts of the string were actually for different consumers of that data ...
- dinkledunk 4y ago
  It's not clueless or sloppy. They are most likely using https://en.wikipedia.org/wiki/JSON_Web_Token https://en.wikipedia.org/wiki/JSON_Web_Token which is a well-defined standard and extremely common in the authentication world because it makes a ton of sense. It lets your authentication server be mostly stateless instead of storing tons of sessions unnecessarily.
  - wizofaus 4y ago
    Never heard JWT pronounced "jot", I've always sounded it out letter by letter. But nor have I ever considered encoding a JWT into a URL!
Avamander 4y ago
I really wish we could send text/markdown emails and have clients support displaying it natively. It would be a nice middle ground.
Anthony-G 4y ago
As a fellow mutt user, I have the same complaints. Sometimes, the confirmation link can be activated by opening the HTML mail in lynx or w3m but in many cases, using the confirmation requires that the browser runs Javascript so I ended up having to copy the link from the terminal emulator, reformat it (remove line breaks and plus symbols) and paste it into Firefox. :( My other annoyance is Mailchimp users sending emails that have the correct message in the HTML part but old or previous content in the plain-text part. That’s even worse than those who simply omit the plain-text part.
account42 4y ago
If wrapping long links causes them to break then does very much sound like an email CLIENT issue.

by jcynix 4y ago

Wowfunhappy 4y ago

> Email does suck, at least HTML email. And that's not just because HTML was and still is the wrong markup tool for email. I mean, citation needed. I’m ready to consider the idea but give me a reason! 95+% of computer users will not want to use a command line.

GrumpySloth 4y ago
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.
jcynix 4y ago
In my day job I use Thunderbird on a Mac, with HTML turned off. Because too many colleagues send Office attachments. So you don't need to use a command line to turn HTML off (but neither do you need to be afraid to use it CLI ;-) Citations: "HTML Email: Whenever Possible, Turn It Off!" https://subversion.american.edu/aisaac/notes/htmlmail.htm https://subversion.american.edu/aisaac/notes/htmlmail.htm https://phishingtackle.com/articles/phishing-emails-with-html-attachments-in-2022/ https://phishingtackle.com/articles/phishing-emails-with-htm...
aendruk 4y ago
Markdown would better serve 95% of the email I see.
- wahern 4y ago
  Indeed, Markdown is literally derived from the markup conventions invented for usenet and e-mail messages.
- joshuamorton 4y ago
  The markdown spec includes the full html spec (https://daringfireball.net/projects/markdown/syntax#html https://daringfireball.net/projects/markdown/syntax#html)
- dont__panic 4y ago
  Agreed wholeheartedly. I'd love to see email clients embrace markdown rendering (and sending) as an alternative to HTML. For stuff like links, headings, bulleted lists, tables, etc. in a single page, markdown is perfect. Emails rarely exceed the complication of a readme, and markdown works amazingly for those. Even better: it remains totally readable in its raw unrendered form. So you're not really forcing anyone else to adopt your syntax, just... nudging.
- pabs3 4y ago
  My MUA (GNOME evolution) supports sending markdown emails.
  - aendruk 4y ago
    That’s a compelling feature. Can you have it actually send as `Content-Type: text/markdown` or does it still convert to HTML for now?
    - pabs3 4y ago
      It offers three markdown mail composition options: Markdown (text/markdown), Markdown as Plain Text (text/plain), Markdown as HTML (text/plain and text/html). Doesn't seem to be a way to have text/markdown and text/html though. It also renders incoming text/markdown emails in a HTML-like way using WebKit, rather than showing the raw markdown data.
gpvos 4y ago
What does the command line have to with non-HTML mail? It's perfectly feasible to have a window-based mail client that creates text mails.
blooalien 4y ago
95+% of computer users who mention not wanting to use or see a command line are so utterly terrified by the command line "bogeyman" that they imagine command lines appearing in places they would actually never be, or be required.

rsync 4y ago

"No, they send their complete state." Oh, so that is what is happening ? When I see these extremely long URLs I know, of course, that someone is being clueless and sloppy and I know, of course, that whatever they are embedding could be hashed or compressed to 64 (or fewer) characters ... But you are saying that what I am witnessing is the entire state of the transaction is being passed in the URL ? I guess I thought that they were passing multiple third party tracking strings all in the same URL and that different parts of the string were actually for different consumers of that data ...

dinkledunk 4y ago
It's not clueless or sloppy. They are most likely using https://en.wikipedia.org/wiki/JSON_Web_Token https://en.wikipedia.org/wiki/JSON_Web_Token which is a well-defined standard and extremely common in the authentication world because it makes a ton of sense. It lets your authentication server be mostly stateless instead of storing tons of sessions unnecessarily.
- wizofaus 4y ago
  Never heard JWT pronounced "jot", I've always sounded it out letter by letter. But nor have I ever considered encoding a JWT into a URL!

Avamander 4y ago

I really wish we could send text/markdown emails and have clients support displaying it natively. It would be a nice middle ground.

Anthony-G 4y ago

As a fellow mutt user, I have the same complaints. Sometimes, the confirmation link can be activated by opening the HTML mail in lynx or w3m but in many cases, using the confirmation requires that the browser runs Javascript so I ended up having to copy the link from the terminal emulator, reformat it (remove line breaks and plus symbols) and paste it into Firefox. :( My other annoyance is Mailchimp users sending emails that have the correct message in the HTML part but old or previous content in the plain-text part. That’s even worse than those who simply omit the plain-text part.

account42 4y ago

If wrapping long links causes them to break then does very much sound like an email CLIENT issue.