Plain text wrapping in Gmail
mathiasbynens.be
mathiasbynens.be
It's ok if they don't support it when displaying mail, but by just setting that flag on sending, people with good clients will get the best possible experience
Email is ancient; it still works; it usually does not need round CSS corners nor bold HTML stuff.
"Modern" clients gives you utter shit like WebTV and midi-file signatures.
Seriously?! Is this a thing? Please tell me that was hyperbole.
Also, this is not just about compatibility with old clients, but also about compatibility with old emails. If you redefine the meaning of previously used email syntax, that changes how old emails get displayed, which sucks if you have an email archive that goes back more than a decade.
But the good thing about format=flowed is that even if a client doesn't support it for display, it'll still look good (on desktops)
The other annoyance I have is with email clients that display plaintext emails in proportional font, which mangles ASCII art diagrams and nicely-aligned tables/columns. The ones that attempt to "rejoin" lines and re-word-wrap also make a similar mess.
If you want to send me ASCII art, use HTML and CSS to specify the font required for display. My email client will default to a font which is pleasant to my eyes. It is ridiculous that my choice of default font should be confined by a tiny subset of email content, especially where the author knows ahead of time that this content is sensitive to the font it is displayed with.
(Also, BTW, your assumption is wrong - the original "display" certainly also included teletype terminals, and CRTs in amber and white, and all the monochrome display variants with inverted colors. What they all had in common, though, was a monospace font.)
It's more accurate to say "by convention" and "assumed", which makes the argument for continuing to insist on monospace weaker.
People have most definitely written mails with the semantically relevant assumption that they will be displayed in a monospace font, and those mails are still around, so the only correct thing to do to maintain compatibility is to display mails that don't indicate support for non-monospace display in a monospace font. It's that simple. Also, obviously, there still are systems around from back then that still produce new emails which also still make that assumption.
Most people, at the present time, have a poor experience when receiving 78 character hard wrapped email.
The correct way is the one that maintains backward compatibility while introducing new features, and that is internally consistent. The error is in thinking that it has to be either old and limited or new and backward incompatible. format=flowed is exactly the solution that makes it so that old clients display mails as their users are used to, and allows newer clients to make use of new display capabilities, so both have a good experience. Breaking backward compatibility in distributed systems in order to make progress tends to be a sign of incompetence.
Format flowed is a reasonable response - it actually meets the definition of 'works for most users' that you say is incompetent, I'm just not sure we want to embed 78 characters for the tiny portion of unmaintained email software that can't display the majority of mail they receive - but arguing in the same passive aggressive way you are:
The correct way is removing presentation from content. This is a very basic principle of engineering and if you're against that I'd suggest you might find the incompetence you mention closer to home.
Sounds a bit childish doesn't it? Since you're new here, you might want to read: https://news.ycombinator.com/newsguidelines.html
Then, your "for the tiny portion of unmaintained email software" mostly says something about how little you know about email software. You might be surprised, but there is a lot of email software out there that is very actively maintained and that has many active users that still expects and produces 78-column hard-wrapped plaintext bodies. It tends to be some of the most mature and powerful email software as well. Plus, there is not just "old" email software, but also old emails. My general expectation of good software is that my data stays readable without any deterioration, and I think many people with many million emails think the same.
Removing presentation from content is completely orthogonal to staying backward compatible to an existing distributed system. That might be an oversight of the original design, but that's water under the bridge, we'll have to work with what we have.
Incidentally, I also think that removing presentation from content is a bad idea for most uses of email, as it makes things hugely more complex without any real benefit that would be worth the additional effort (both in the implementation and for the user), at least when it goes beyond reflowable paragraphs as provided by format=flowed, that seems simple enough to me. As I said elsewhere in this thread, just because TeX and DTP are a good idea for the layout of books, doesn't mean a pencil is the wrong tool for a shopping list. Contrary to what you claim, it's not really all that fundamental a principle - it's a methodology software engineers should be aware of, including its dis- and advantages, and that has huge benefits when you need to maintain(!) tons of similar or particularly large, regular, documents, but emails mostly just don't fall into that category, so the additional effort is mostly counterproductive.
It sounds incredibly powerful if it can't handle the vast majority of email produced currently.
Also, surprisingly, I, for one, don't have to read the majority of email produced. It's perfectly sufficient if I can read those emails that I receive, and the vast majority of those fit within those limitations without any problems.
Hell, my guess is that the LKML (https://lkml.org/) alone probably is the majority of my incoming mail, and that one essentially runs on "old" email clients. Though I guess that in your eyes that's a sign that the majority of kernel developers just are too stupid to know what a powerful MUA looks like ...
> What does the vast majority of email produced currently look like and how do you know?
I don't think anyone has access to the majority of the world's email, so the best we can do is take a sample of general purpose mail servers and mailing lists, of which I've run many.
However: you're arguing that the vast majority of email conforms to your rules (after all, we wouldn't consider email software maintained unless it could actually handle most email - I hope you agree but at this point I wouldn't be surprised if you didn't). This is a pretty fantastical claim, and the only proof you've been able to provide is personal experience of a mailing list with single specialist audience. Which seems much weaker. In fact, that that mailing list needs to tell people what mail clients to use seems to prove my point rather than your own.
I didn't say kernel developers don't know what a powerful MTA is.
I didn't say anyone was stupid.
You're new here and you keep breaking the HN guidelines. Perhaps you'd be better suited to a different website?
Your point being?
> However: you're arguing that the vast majority of email conforms to your rules
Please read more carefully.
> In fact, that that mailing list needs to tell people what mail clients to use seems to prove my point rather than your own.
Mind to elaborate?
> Your point being?
LKML is a poor representation of email users.
>> However: you're arguing that the vast majority of email conforms to your rules
>Please read more carefully.
If you're not arguing that, you're arguing that despite most email not being formatted to 78 character displays, email clients which can't display most email are acceptable, which seems even more ridiculous.
>> In fact, that that mailing list needs to tell people what mail clients to use seems to prove my point rather than your own.
> Mind to elaborate?
The presence of specific mailing list client guidelines indicate that most email is not formatted to 78 character displays, a notion which you were challenging earlier.
Which is relevant how?
> If you're not arguing that, you're arguing that despite most email not being formatted to 78 character displays, email clients which can't parse most email are acceptable and not poor, which seems even more ridiculous.
First of all, I didn't make any claims about what most emails look like. Just because I don't believe what you claim, doesn't mean I believe the opposite. I don't know, and as far as I can tell, you don't either. And it's irrelevant anyhow, as people might just not be receiving a representative sample of the emails out there, so it would be idiotic to give up advantages of your own mailer because it would not be able to parse mails that you don't even receive.
Other than that, your thinking seems to be pretty one-dimensional. Email clients have more qualities than their ability to parse emails with lines longer than 78 characters (obviously, this is not really about them being unable to parse those lines, as in crashing or not displaying the mail at all, but about suboptimal handling), and some of those qualities might outweigh any disadvantage due to that. Also, it might just be that 78 character plain text mails are actually inherently superior to all the alternatives, in which case, even if the majority of emails today does not fit into that category, the sensible solution still would be to improve MUAs that send other formats rather than to make the older MUA support the inferior formats that are being widely used.
> The presence of specific mailing list client guidelines indicate that most email is not formatted to 78 character displays, a notion which you were challenging earlier.
Maybe you want to read the LKML's actual FAQ? Those "client guidelines" have very little to do with a 78 character limit, and all with how one can efficiently communicate using email, how some of the more well-known bugs in various MUAs hinder that, and how one can work around those problems. Some of that is specific to software development, but most of it really isn't at all. It just so happens that many newer MUAs tend to not support efficient work flows that have stood the test of time very well, and don't really offer any sensible alternatives either, and also tend to lack in interoperability with those (mostly older) MUAs that do support those well-working workflows.
Do you still not believe most email is formatted at 78 characters? Really? I've stated my reasoning, you haven't refuted that or explained any alternative.
> it might just be that 78 character plain text mails are actually inherently superior to all the alternatives
No, we've already discussed why they're worse and you haven't even attempted to rebut it.
> Maybe you want to read the LKML's actual FAQ?
Yes, I have, and I'm aware that Linux kernel developers have other ideas about email workflows, eg, not 'top posting', again, they not representative of common email use cases, for the same reasons I have mentioned earlier, which you have not refuted in any way.
> Email clients have more qualities than their ability to parse emails with lines longer than 78 chars
They do, but displaying email is a critical part of email clients.
> Other than that, your thinking seems to be pretty one-dimensional.
Another part of email list etiquette: read the rules or go somewhere else: https://news.ycombinator.com/newsguidelines.html
You've essentially stated that you don't know either (you haven't really read your users' emails, have you?), and I have explained why it doesn't matter anyhow, so I don't see any need to refute anything.
> No, we've already discussed why they're worse and you haven't even attempted to rebut it.
No, we haven't.
> they not representative of common email use cases
(a) Yes, they are - are you maybe confusing use cases (what it's for) with workflows (how it's applied to that use case)?
(b) How exactly is that even relevant? Because linux kernel developers are not representative of email users, it's fine to break email in a way that doesn't work for linux kernel developers? I mean, kinda my whole initial point was that exactly that is terrible engineering.
> for the same reasons I have mentioned earlier
Actually, you haven't.
> which you have not refuted in any way.
As such, there is little to refute.
> They do, but displaying email is a critical part of email clients.
so?
> Another part of email list etiquette:
Part of that is that you sincerely try to understand the other side's position, don't quote out of context, don't misrepresent, don't just repeat talking points without actually considering and addressing the other side's arguments, question your own implicit assumptions, ... - that avoids the frustration that you are seeing there.
If you edit the email and send, they now add more hard newlines for where the new line endings are and you end up with a mix of tiny lines and normal lines looking like your email is written in free verse.
I wrote about this here: http://adamlafave.com/email-parsing-dont-parse-text-plain/
However, this article is hilariously bad, promotes bad practice concentrating on completely irrelevant issues and offering bad advice. Wrapped text is good, this has been talked to death so I won't repeat it here. Beside being bad style is general, non-wrapped e-mails are very strongly correlated to bad messages. If someone posts non-wrapped e-mails, or worse, HTML on a mailing list it's a very strong cue that person doesn't know what he's talking about, so it's a great way to ignore useless e-mails.
Gmail is bad because you can't turn wrapping off. On by default is a great default, it's just awful you can't turn it off when posting code or diffs.
Even worse, Gmails started converting tabs to spaces, and eliding leading indentation completely making it absolutely useless as a patch delivery mechanism. The new age auto-reflow stuff also interferes with this.
[1] https://www.kernel.org/doc/Documentation/email-clients.txt
Even though the stack of email RFCs contains quite some cruft due to historic accidents, it's actually not as bad as you might think when looking at all the terrible mail software out there that seems to be written by people who don't even bother to read the RFCs (which seems to include google, after all).
Quite a while ago I considered trying to write an IMAP library for a language I used - after some brief research I concluded: that way lies madness.
http://en.wikipedia.org/wiki/Large-sized_note
Which in turn apparently goes back to taking a common paper size and cutting it into reasonably-sized pieces:
http://ask.metafilter.com/262846/What-is-the-origin-of-the-d...
So apparently one person lost to history said, "How big should it be? I don't know. Maybe about this big?" Centuries later, somebody at IBM said, "It looks like we could fit 80 columns on that. Good enough?"
Do you have any primers to use mutt? I really wanted a terminal-based alternative to Thunderbird in case I need to ssh from somewhere, or if I'm in a hurry, but the man page alone scares me.
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
Ultimately, email should be content only, and display handled on the display device.
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.
// 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'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.
I completely agree with the soft wrapping of emails though.
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.
That method is broken unless we also agree on a tab width, in which case we may as well use spaces anyway.
[2] http://i5.minus.com/iu14dVi9QRTri.png [3] http://i4.minus.com/itno9LlgJobQD.png
function declaration (most people would accidentally use too many tabs here):
public void severalParameters(String one, int two, String three,
StringObject four, AnotherObject five) {
...
}
String text = "text";
int a = -1;
History.Entry entry = new History.Entry(text);
public void severalParameters(String one, int two, String three,
StringObject four, AnotherObject five) {
// No problems here. It's just like my example.
// We're two levels of indentation in for these comments.
// The argument list continuation was at 1-level indentation with spaces for alignment
}
String text = "text";
int a = -1;
History.Entry entry = new History.Entry(text);As with any coding standard, the point of the rule is to eliminate such sources of lost productivity.
Don't do that. It looks ugly on my tab-indented, proportional font display.
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.
And, on top of that, the mails are sent with the Calibri font. (Sorry for the off-topic)
Every mail client - including text mode ones like Pine - supports HTML formatted emails, even if they end up displaying them without formatting.
Why should I wastefully send unneeded markup that inflates the size of my email several times larger than what's actually needed?
Similarly, I’d be quite annoyed if my local IMAP cache took five to ten times as much space than it does at the moment for no reason whatsoever (other than filling up an extra 8 to 18 GB).
I can see from the downvotes that some HN users are excessively passionate about their plain text emails, but many people do prefer the extra formatting and layout that a well-constructed HTML email can provide.
This can be observed in general by the fact that almost everyone uses web browsers like Internet Explorer, Firefox and Chrome - rather than Lynx.
In order to compose an HTML email that actually takes advantage of the power of HTML, you have to grasp the abstraction between what you see on the screen and the underlying document structure, and how that underlying structure might be rendered by different receiving MUAs - something that most users don't grasp at all, and also a problem that's not particular to HTML email, but one that is well-known to affect all WYSIWYG authoring tools, and one that is known to be particularly problematic with document types that can be rendered very differently depending on the "medium".
By contrast, the typewriter style interface of plain text email composition is something that's completely intuitive to most people, and people easily succeed at composing an email that reliably will be rendered at the receiving end exactly as they expect - and most of the structure that you need for most email correspondence can actually easily be constructed manually from individual characters (headings, paragraphs, lists, numbered lists, ...).
Also, it can be observed that almost everyone reads books and journals typeset with TeX or DTP software. That's not exactly a good reason against creating your shopping list with a pencil.
For people who are sending email with no HTML features it seems weird to inflate that email with unused unseen cruft.
Many people send email that makes minimal use of HTML features. They perhaps have an auto-appended footer with useless information that is in italics. It's debatable whether the extra size of HTML email is worth it for such minor formatting.
But no one is suggesting that the tiny number of people who "prefer the extra formatting and layout that a well-constructed HTML email can provide" should use plain text emails.
> This can be observed in general by the fact that almost everyone uses web browsers like Internet Explorer, Firefox and Chrome - rather than Lynx.
No. Poor quality design has meant that much of the modern web is unusable for many web browsers. Not just "specialist" browser such as Lynx but for some versions of the browsers you list.
I've seen plenty of poorly constructed HTML emails sent by people who decided that since they can have twelve different fonts in five sentences, with italics, bold, outline, underline and strikethrough thrown in, they should do so. It's almost like they have set themselves a challenge to use every feature of their email client in every message.
Plain text, on the other hand, always looks sensible, well-formed and well constructed to me. This leaves it to the sender to write something worth the effort of reading.
> [...] but many people do prefer the extra formatting and
> layout that a well-constructed HTML email can provide.
In a non-professional context (mailing lists, personal communications), I do just fine with plain-text; in a professional context, I loathe receiving e-mails that utilise what HTML brings because it's nearly always abused in the form of excessive signatures or massive legalese footers shrunk to 6pt, italicised, and rendered in nearly invisible grey.
Any content that really requires the extra formatting and layout offered by HTML would probably be better sent as an attachment anyway. I've lost count of the number of times I've had excerpts from spreadsheets or brochures pasted into an e-mail which have then been mangled in transit, or stretch way off the screen.
What should be done, I believe, is that e-mail _clients_ should detect the 78-character convention and rejoin the lines into paragraphs if they think it would be best.
What Gmail does when sending mail is right, and the alternative view is that this convention should be dead and they should just throw it away and send very long lines.
Any client program can wrap as appropriate (which is not always to 80 chars, but 80 chars would work as well as anything) with QP; the same is not true of hard-wrapped as gmail does it.
Yes, the point of the convention is to make text fit on the 80 char terminal. Nowadays clients use extremely different viewer widths, thus it's an outdated recommendation, that should not be followed anymore.
That’s what format=flowed allows. The sending client line-wraps long lines at 78-or-so characters and then indicates having done so by appending an extra space at the end of such lines. This way, clients can either
(a) leave everything as-is, the trailing spaces won’t hurt or
(b) rejoin the lines into one long paragraph.
But really, this is pretty standard in mail clients…
Edit: added quotation mark, sorry.
Making text fit on a 80-character fixed-width screen is not something the email sender should do; the recipient’s email client should do it based on their preferences.