4 ms·
That “solution” won't help at all. 78 limit is about the client UI and its inability to wrap[1] and the lines still will be longer than 78 chars after decoding.
by lelf 12y ago
That “solution” won't help at all. 78 limit is about the client UI and its inability to wrap[1] and the lines still will be longer than 78 chars after decoding. (How and why exactly this matters in 2014 is another story.)
[1] http://tools.ietf.org/html/rfc2822#section-2.1.1 http://tools.ietf.org/html/rfc2822#section-2.1.1
- nailer 12y ago(you don't need to link to RFC2822 section 2.1.1, it's linked to in the article that you just read) I'm quite familiar with the 78 line break as a Unix user for the last 15 years, but Section 2.1.1 is RFC 2822 should never have been carried forward from RFC 822, where it was originally written decades ago: - There are many displays less than 78 characters wide. - There are many displays more than 78 characters wide. - Most apps that run on displays that are 78 characters wide can happily display paragraphs in their available width. The IETF is wrong. For that matter, I even wrote a Chrome extension to specifically fix reading IETF papers: https://github.com/mikemaccana/deneckbeard https://github.com/mikemaccana/deneckbeard
- rakoo 12y agoTo me the 78 line break is still relevant, not because my displays are small, but because wider texts are less readable.
- nailer 12y agoThat's a legitimate concern: 8-12 words per line was tested and found to be optimal some years ago in print, and the web since 2001, where it was called 'snake text' http://www.suck.com/daily/2001/01/15/ http://www.suck.com/daily/2001/01/15/. However a hard 78 character limit isn't exactly 8-12 characters, and hard broken lines will still look poor on small displays. Ultimately, email should be content only, and display handled on the display device.
- sp332 12y agoThe recipient client's limitations shouldn't limit me as a sender. If I want to include a long code sample, or some concrete poetry, gmail shouldn't step on my toes. I don't mind the current behavior being the default, but it should be settable.
- rch 12y agoThat's fine, just as long as you also recognize the recipient's ability to configure away your code sample and poetic white space entirely. Configurable pattern heuristics to help me, as a recipient, optimally render text would be much more welcome than any capability that could be provided to me as a sender.
- nailer 12y agoCode and poetry can be formatted with whatever line breaks you want. We're just talking about not putting CRs in the middle of paragraphs.
- sp332 12y agoReally? I thought the article said that lines would be hard-wrapped after 78 characters.
- nailer 12y agoI can send you a very long message, in a paragraph, like this. It has a lot of words, and display is determined by the software running on the display device. Immediately afterwards I can include some code: // Do a thing. This a pretty boring example, but it's here to // illustrate a point. I've hard wrapped it to fit at some // arbitrary length var foo = 'bar'
- Timmmmbob 12y agoSo, word wrap? This is the same stupid argument that pro-spaces people make in the tabs-vs-spaces argument - that you have to use spaces (or hard line breaks) so that you can force your ideal indent size (or line length) on other people. Just accept the other people have different preferences, and tabs and soft word-wrapping enables them to use their preference. If you don't then you're being selfish really.
- xixixao 12y agoYou cannot align things on different lines with soft tabs. If you really need to change the indentation, you could always do it based on spaces (not that I have seen any editors capable of doing it) - again, you will mess up the alignment. I completely agree with the soft wrapping of emails though.
- manicdee 12y agoWhat things are you aligning on different lines? Are you stuffing spaces between variables and assignment operators "a = 1"? Don't do that. It looks ugly on my tab-indented, proportional font display.
- planckscnst 12y agoUsually, it's argument lists that need aligning. I personally hate aligned assignments. I find it very sloppy. But yes, that is what you would do if you so wanted aligned assignments. Using only tabs, you cannot do aligned assignments unless you are able to set specific tab stops per line. If you disagree, I can provide an assignment example that breaks tabs. While per-line tab stops might be possible, the overhead of maintaining tab stops vs not using aligned assignments is not worth it.
- planckscnst 12y agoThat is correct, you can't align things on different lines with soft tabs. So don't do it! When using tabs, only use them for semantic indentation, not for alignment. In most cases, to align things: enter a newline character, tab-in the same number of tabs as the previous line, then add spaces to align. This is the one true correct way because it allows anybody to use any size tabs imaginable and still works without breaking alignment. Unfortunately, the world is full of people who don't understand this, so when tabs are used, they are used incorrectly (for alignment). Therefore, the one truerest way is (unfortunately) spaces for both indentation and for alignment. I've come to accept this non-ideal solution as a consequence of the wonderful but imperfect nature of Humanity.