4 ms·

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
    - nailer 7y ago
      > 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 Precisely. HTML and markdown separate content from presentation, so content that should never be wrapped - like ```code``` or <blockquote>code</blockquote> is handled properly.
      - u801e 7y ago
        Yes, but that doesn't have a sensible fallback for clients that don't support html or markdown. format=flowed does have a sensible fallback.
        deleted 7y ago
        [deleted]

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
  - nailer 7y ago
    > 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 Precisely. HTML and markdown separate content from presentation, so content that should never be wrapped - like ```code``` or <blockquote>code</blockquote> is handled properly.
    - u801e 7y ago
      Yes, but that doesn't have a sensible fallback for clients that don't support html or markdown. format=flowed does have a sensible fallback.
      - deleted 7y ago
        [deleted]