5 ms·

Some people sending plain text mails also wrap them manually. If my window is small (maybe because I am using a small screen), the text is painful to read. And

by jraph 7y ago

Some people sending plain text mails also wrap them manually. If my window is small (maybe because I am using a small screen), the text is painful to read. And a non manually wrapped plain text is not wrapped at all in some cases. By all means, send me plain text mails, it will be lighter for my self-hosted inbox, but don't wrap them manually. If you are going to abuse /this/ kind of `formatting`, however, you are making your mail harder to read for me. These are tags anyway, just not HTML tags. I'd prefer you use the real formatting that is correctly handled in most cases, but I will adapt. > There are two main types of emails on the internet: plaintext and HTML. The former is strongly preferred You will need to back this up because this is not what I observe. My email client takes care of my privacy and my security, and you can use it too if you are concerned, it's a cross platform maintained free software. It's okay. My problems with HTML emails is colors: if you want to use something like a night mode, you will see emails with hard coded white background and black texts, or worse, only black texts. You may be able to ignore colors but people will assume you can see them. Maybe an extension like dark background on light texts when using a browser for reading emails who do the trick, but I don't.

bo1024 7y ago
I'm very sad about manual line wrapping too (since I love plain text otherwise), but unfortunately it's in the MIME standard. > Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF. Of course with HTML, your source code can adhere to this standard while still having arbitrarily long lines of text... https://mailformat.dan.info/body/linelength.html https://mailformat.dan.info/body/linelength.html
- jorangreef 7y ago
  The RFC you quoted actually refers to line lengths within a MIME message as a whole (headers and body), and only after Content-Transfer-Encoding has been applied, not before. In other words, your text parts can have lines of arbitrary line length, provided you encode them as QuotedPrintable or Base64 and set the Content-Transfer-Encoding header accordingly, which most email clients do.
  - bo1024 7y ago
    Thanks for the correction!
- mrzool 7y ago
  It’s an outdated standard and a terrible idea nowadays, since it makes emails unreadable on mobile devices. I’d really love to use plain-text emails — hell, I use plain text for everything — but they’re sadly not a good idea today, unless you want your emails looking like crap on every mobile device. The suggestion to use `format=flowed` doesn’t help, as the standard is ill-supported: https://fastmail.blog/2016/12/17/format-flowed/ https://fastmail.blog/2016/12/17/format-flowed/ I’ve researched the issue far and wide and the only way to have responsive, nicely wrapped emails is using HTML.
  - cpbotha 7y ago
    This is the one blemish (in my view) on fastmail's record. I love them otherwise. I initially came to the same conclusion as you, but after receiving one too many badly quoted HTML emails (and after some lost hours unsuccessfully trying to understand how fastmail web, gmail, thunderbird and ios mail.app do HTML quoting (hint: they're all subtly different)), I decided to double-down on format=flowed.
  - u801e 7y ago
    The main arguments in the fastmail blog you reference are: 1. Lack of support 2. Lack of people sending/reading plain text email 3. HTML bloat is no longer a real concern Then they make some implementation difficulty arguments 1. Implement an editor that supports only semantic blockquoting 2. Fix "embarrassing line wrap" due to clients that lack support For the first 3 arguments, I would say that lack of support from other clients doesn't mean that a client shouldn't support it. I regularly posted to usenet with Thunderbird (which supports format=flowed) and had people respond to my posts with clients that didn't support that feature. To them (and when viewing the message source), the messages still appeared to be hard-wrapped. When viewing the messages in Thunderbird, the parts I typed were softwrapped. "Embarrassing line wrap" simply did not happen (no matter many times a given piece of text was quoted). "Embarrassing line wrap" was only an issue because certain clients would further re-wrapped quoted text without taking the quote markers into account instead of just leaving it alone or properly re-wrapping it. Text editors like emacs and vim have features that will easily re-wrap quoted email text. Thunderbird has a feature where you can highlight quoted text and press ctrl-r to rewrap it. So I don't really see how it's difficult to eliminate the "embarrassing line wrap" issue when there are open source programs out there that have the capability (for several decades now) to fix it. And I think they're missing the point by saying that HTML bloat is no longer an issue. It's not the amount of text that's transferred; it's how readable it is in a client that doesn't support rendering that text. IOW, reading raw HTML is not that easy. As for implementing an editor that only supports semantic block quoting, I think they're missing the point again. It should be the person who's composing the email who decides whether a particular section of text should be hard-wrapped (meaning no trailing whitespace at the end of each line). You could have a feature where you highlight the text you want hardwrapped and then use a key combination or context menu to apply that change. The rest of the text is assumed to be soft-wrapped and will have trailing whitespace at the end of each line unless that line followed by a blank line.
u801e 7y ago
> If my window is small (maybe because I am using a small screen), the text is painful to read. And a non manually wrapped wrapped plain text is not wrapped at all in certain cases. If the MUA (Mail User Agent) does not soft wrap text, then text without hard wraps is painful to read. This also applies to text that's not meant to be soft wrapped (source code, error message output, log messages, etc.). There is an RFC [1] that addresses this issue by introducing a format= flowed option in the MIME headers. [1] https://www.ietf.org/rfc/rfc3676.txt https://www.ietf.org/rfc/rfc3676.txt
- Boulth 7y ago
  Sadly f=f is not widely supported (Thunderbird is a notable client using it).
swiley 7y ago
I’m pretty sure hard wrapping at 80(?) chars is part of one of the RFCs.
chapium 7y ago
hard wrap at 72 characters seems pretty conservative
- jraph 7y ago
  This will wrap badly on many phones in portrait mode. The only hard wrapping that will probably not break anyone's workflow for sure is 1.
- u801e 7y ago
  The reason it's 72 characters is to allow for quoted text, which gets indented relative to the new text. That would allow a line in an email that's 72 characters long to still fit within 80 characters if it's prefixed with 8 quote characters. For example: >>>>>>>>This line was 72 characters long, but is now 80 characters long instead.
  - nailer 7y ago
    Still looks pretty bad on anything less than 72 characters because there's random newlines in the middle of paragraphs. Content should be separated from presentation. Additionally 72 characters implies monospace fonts which have been shown to be less readable.
    - u801e 7y ago
      > Content should be separated from presentation. Not necessarily. There are times where text should not be wrapped (code snippets, error messages, or log output), but if text is softwrapped, then there's no way to prevent that text from getting wrapped unless you use some time of mark up like HTML or markdown. This requires that the client supports that type of markup which isn't always the case. There is an RFC[1] that describes the format=flowed option in the MIME headers that addresses the wrapping issue (where text that should be soft-wrapped should have trailing whitespace at the end of each line). That would work with email clients that support that feature and will still appear to be hard-wrapped to email clients that do not. So, unlike HTML or markdown, we don't require those who use clients that only support plain text to update their clients to support a new feature. We can use that feature in clients that support it and have a sensible fallback for clients that do not. [1] https://www.ietf.org/rfc/rfc3676.txt https://www.ietf.org/rfc/rfc3676.txt
upofadown 7y ago
>If my window is small (maybe because I am using a small screen), the text is painful to read. If your screen is so small that it can't display 80 characters across then pretty much anything you look at it with is going to look odd. Any HTML formatting such as tables will also be painful to read.
- gdfasfklshg4 7y ago
  Have you ever seen someone with poor eyesight use a smart phone?
- rusk 7y ago
  You’re missing the point that anything longer than 80 chars is harder for the human. Ideally it should be 65. That said, wrapping is better left to the mail client, and let the user adjust their window to suit. My chief gripe at this point is that some email clients (gmail anyway) will get confused by outsized inline images and wrap on them, even if that means letting text drift off the side of the screen!
- jraph 7y ago
  I like big characters. I can be far from my screen to read, use a low brightness and never have tired eyes. I just checked on my phone some random opened web page: with my settings (which are far from the default - I raise the DPI setting and the font size so I have small UI elements but big texts), it displays 45 characters per line on portrait mode. Actually the font size is a bit too high, but I don't really care as far as most web pages are readable. I'm fine with scrolling the occasional big HTML table, and will change the settings if this becomes annoying. So, yes, sometimes, my screen displays less than 80 characters and is perfectly usable. And this fact is not really of my correspondent's business, whether they choose to manually wrap at 80 characters, 72 characters, 42 characters or some other arbitrary number of characters. Actually, nobody knows that apart from people who read this comment. I display text as I see fit (and this is totally an intended pun).

by jraph 7y ago

bo1024 7y ago

I'm very sad about manual line wrapping too (since I love plain text otherwise), but unfortunately it's in the MIME standard. > Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF. Of course with HTML, your source code can adhere to this standard while still having arbitrarily long lines of text... https://mailformat.dan.info/body/linelength.html https://mailformat.dan.info/body/linelength.html

jorangreef 7y ago
The RFC you quoted actually refers to line lengths within a MIME message as a whole (headers and body), and only after Content-Transfer-Encoding has been applied, not before. In other words, your text parts can have lines of arbitrary line length, provided you encode them as QuotedPrintable or Base64 and set the Content-Transfer-Encoding header accordingly, which most email clients do.
- bo1024 7y ago
  Thanks for the correction!
mrzool 7y ago
It’s an outdated standard and a terrible idea nowadays, since it makes emails unreadable on mobile devices. I’d really love to use plain-text emails — hell, I use plain text for everything — but they’re sadly not a good idea today, unless you want your emails looking like crap on every mobile device. The suggestion to use `format=flowed` doesn’t help, as the standard is ill-supported: https://fastmail.blog/2016/12/17/format-flowed/ https://fastmail.blog/2016/12/17/format-flowed/ I’ve researched the issue far and wide and the only way to have responsive, nicely wrapped emails is using HTML.
- cpbotha 7y ago
  This is the one blemish (in my view) on fastmail's record. I love them otherwise. I initially came to the same conclusion as you, but after receiving one too many badly quoted HTML emails (and after some lost hours unsuccessfully trying to understand how fastmail web, gmail, thunderbird and ios mail.app do HTML quoting (hint: they're all subtly different)), I decided to double-down on format=flowed.
- u801e 7y ago
  The main arguments in the fastmail blog you reference are: 1. Lack of support 2. Lack of people sending/reading plain text email 3. HTML bloat is no longer a real concern Then they make some implementation difficulty arguments 1. Implement an editor that supports only semantic blockquoting 2. Fix "embarrassing line wrap" due to clients that lack support For the first 3 arguments, I would say that lack of support from other clients doesn't mean that a client shouldn't support it. I regularly posted to usenet with Thunderbird (which supports format=flowed) and had people respond to my posts with clients that didn't support that feature. To them (and when viewing the message source), the messages still appeared to be hard-wrapped. When viewing the messages in Thunderbird, the parts I typed were softwrapped. "Embarrassing line wrap" simply did not happen (no matter many times a given piece of text was quoted). "Embarrassing line wrap" was only an issue because certain clients would further re-wrapped quoted text without taking the quote markers into account instead of just leaving it alone or properly re-wrapping it. Text editors like emacs and vim have features that will easily re-wrap quoted email text. Thunderbird has a feature where you can highlight quoted text and press ctrl-r to rewrap it. So I don't really see how it's difficult to eliminate the "embarrassing line wrap" issue when there are open source programs out there that have the capability (for several decades now) to fix it. And I think they're missing the point by saying that HTML bloat is no longer an issue. It's not the amount of text that's transferred; it's how readable it is in a client that doesn't support rendering that text. IOW, reading raw HTML is not that easy. As for implementing an editor that only supports semantic block quoting, I think they're missing the point again. It should be the person who's composing the email who decides whether a particular section of text should be hard-wrapped (meaning no trailing whitespace at the end of each line). You could have a feature where you highlight the text you want hardwrapped and then use a key combination or context menu to apply that change. The rest of the text is assumed to be soft-wrapped and will have trailing whitespace at the end of each line unless that line followed by a blank line.

u801e 7y ago

> If my window is small (maybe because I am using a small screen), the text is painful to read. And a non manually wrapped wrapped plain text is not wrapped at all in certain cases. If the MUA (Mail User Agent) does not soft wrap text, then text without hard wraps is painful to read. This also applies to text that's not meant to be soft wrapped (source code, error message output, log messages, etc.). There is an RFC [1] that addresses this issue by introducing a format= flowed option in the MIME headers. [1] https://www.ietf.org/rfc/rfc3676.txt https://www.ietf.org/rfc/rfc3676.txt

Boulth 7y ago
Sadly f=f is not widely supported (Thunderbird is a notable client using it).

swiley 7y ago

I’m pretty sure hard wrapping at 80(?) chars is part of one of the RFCs.

chapium 7y ago

hard wrap at 72 characters seems pretty conservative

jraph 7y ago
This will wrap badly on many phones in portrait mode. The only hard wrapping that will probably not break anyone's workflow for sure is 1.
u801e 7y ago
The reason it's 72 characters is to allow for quoted text, which gets indented relative to the new text. That would allow a line in an email that's 72 characters long to still fit within 80 characters if it's prefixed with 8 quote characters. For example: >>>>>>>>This line was 72 characters long, but is now 80 characters long instead.
- nailer 7y ago
  Still looks pretty bad on anything less than 72 characters because there's random newlines in the middle of paragraphs. Content should be separated from presentation. Additionally 72 characters implies monospace fonts which have been shown to be less readable.
  - u801e 7y ago
    > Content should be separated from presentation. Not necessarily. There are times where text should not be wrapped (code snippets, error messages, or log output), but if text is softwrapped, then there's no way to prevent that text from getting wrapped unless you use some time of mark up like HTML or markdown. This requires that the client supports that type of markup which isn't always the case. There is an RFC[1] that describes the format=flowed option in the MIME headers that addresses the wrapping issue (where text that should be soft-wrapped should have trailing whitespace at the end of each line). That would work with email clients that support that feature and will still appear to be hard-wrapped to email clients that do not. So, unlike HTML or markdown, we don't require those who use clients that only support plain text to update their clients to support a new feature. We can use that feature in clients that support it and have a sensible fallback for clients that do not. [1] https://www.ietf.org/rfc/rfc3676.txt https://www.ietf.org/rfc/rfc3676.txt

upofadown 7y ago

>If my window is small (maybe because I am using a small screen), the text is painful to read. If your screen is so small that it can't display 80 characters across then pretty much anything you look at it with is going to look odd. Any HTML formatting such as tables will also be painful to read.

gdfasfklshg4 7y ago
Have you ever seen someone with poor eyesight use a smart phone?
rusk 7y ago
You’re missing the point that anything longer than 80 chars is harder for the human. Ideally it should be 65. That said, wrapping is better left to the mail client, and let the user adjust their window to suit. My chief gripe at this point is that some email clients (gmail anyway) will get confused by outsized inline images and wrap on them, even if that means letting text drift off the side of the screen!
jraph 7y ago
I like big characters. I can be far from my screen to read, use a low brightness and never have tired eyes. I just checked on my phone some random opened web page: with my settings (which are far from the default - I raise the DPI setting and the font size so I have small UI elements but big texts), it displays 45 characters per line on portrait mode. Actually the font size is a bit too high, but I don't really care as far as most web pages are readable. I'm fine with scrolling the occasional big HTML table, and will change the settings if this becomes annoying. So, yes, sometimes, my screen displays less than 80 characters and is perfectly usable. And this fact is not really of my correspondent's business, whether they choose to manually wrap at 80 characters, 72 characters, 42 characters or some other arbitrary number of characters. Actually, nobody knows that apart from people who read this comment. I display text as I see fit (and this is totally an intended pun).