3 ms·
> Content should be separated from presentation. Not necessarily. There are times where text should not be wrapped (code snippets, error messages, or log outp
by 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 agoYes, 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]