Hacker News new | past | comments | ask | show | jobs | submit login
Plain text wrapping in Gmail (mathiasbynens.be)
171 points by daw___ on July 6, 2014 | hide | past | web | favorite | 90 comments



Google should sent plain text mail with format=flowed (http://www.ietf.org/rfc/rfc2646.txt) as that would fix the issue for both very old clients which profit from the hard line breaks while still providing word wrapping on mobile clients.

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


by old clients, that is pre-2000's era email clients. Why are we supporting ~15 year old email clients anyways?


Because there is no need not to.

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.


> midi-file signatures

Seriously?! Is this a thing? Please tell me that was hyperbole.



Because they are being used? (In turn because they tend to be the best ones around, most of the newer email software tends to be crap if you go by productivity rather than shininess.)

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.


Gmail doesn't support format=flowed, so from that perspective, it too is an old client. Last time I checked, one of the most widely used non-web clients also didn't support it (Outlook).

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)


While I don't agree with Gmail automatically inserting linebreaks, 78 is basically the convention for plaintext email (and mailing lists often enforce this rule), so I do keep my lines within 80 characters and don't like it when others send everything on one line. The same applies to plaintext files, e.g. READMEs and related documentation, so I don't see why it should be any different for email. If you want to do something more fancy, use HTML instead.

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.


> 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.

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.


You have it backwards. The original display of plain text email was monospace, so that's by definition the correct way, as you otherwise break backward compatibility. HTML is the one which defaults to a font of the user's choice. So, if you want to send a mail that is to be displayed in a font of the user's choice, you need to send an HTML mail. Or you could use format=flowed, which has better compatibility with non-HTML-capable clients, and also allows display in a proportional font.


The original display of plain text email was on monochromatic green "P1" phosphor screens, so that's by definition the correct way. Otherwise, you break the expectation that the text will be green.


You are telling me that you don't recognize that it's about keeping the meaning of emails constant and not about reproducing the exact pattern of photons? Or are you telling me that there are emails out there that only make sense/are readable when displayed in green on black?

(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.)


I was merely taking issue with your use of "by definition" and "correct". :)

It's more accurate to say "by convention" and "assumed", which makes the argument for continuing to insist on monospace weaker.


This is not a philosophical argument, but about interoperability in a distributed system. Interoperability is all about conventions, by definition. Therefore, doing what is convention and what is reasonably assumed by participants in the system is, indeed, correct, by definition, unless there is an overriding concern, like security.

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.


The correct way is the one that works in most cases.

Most people, at the present time, have a poor experience when receiving 78 character hard wrapped email.


No, that's the thinking that's causing so much of the breakage in today's IT world.

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.


The breakage with inserting carriage returns in the middle of paragraphs at a fixed display size is already illustrated in the article.

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


First of all, you might not have noticed, but I said that breaking backward compatibility [...] is a sign of incompetence. format=flowed was invented specifically because it doesn't break backward compatibility. And that is why it is good. That it might also meet the definition of "works for most users" is somewhat incidental. As you might also not have noticed, I didn't claim that something working for most users was bad, it just isn't sufficient.

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.


> software that is very actively maintained that still expects and produces 78-column hard-wrapped plaintext bodies... some of the most mature and powerful email software as well.

It sounds incredibly powerful if it can't handle the vast majority of email produced currently.


What does the vast majority of email produced currently look like and how do you know?

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 ...


LKML has very strict rules as it's primarily used for patches the Linux kernel. Other mailing lists, as you may be aware, are not primarily used for software patches, since most human beings, as I would hope you realise but perhaps don't, are not software developers.

> 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?


> LKML has very strict rules as it's primarily used for patches the Linux kernel. Other mailing lists, as you may be aware, are not primarily used for software patches, since most human beings, as I would hope you realise but perhaps don't, are not software developers.

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?


>> LKML has very strict rules as it's primarily used for patches the Linux kernel. Other mailing lists, as you may be aware, are not primarily used for software patches, since most human beings, as I would hope you realise but perhaps don't, are not software developers.

> 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.


> LKML is a poor representation of email users.

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.


> Just because I don't believe what you claim, doesn't mean I believe the opposite.

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


> 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.

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.


table preservation and subsequent extraction becomes complex when the tables are in a forwarded email and there's a quote prefix (e.g. '> ') which takes one or more line lengths above 78 and then somewhere along the chain single table rows will then be split into multiple lines. In these cases, it takes all the kings horses and all the kings men to put humpty dumpty back together again.


If a MUA breaks lines in quoted text (not to be confused with reflowing format=flowed!), that's a bug in the MUA. While email isn't trivial, it's not _that_ difficult either, if people cared.


Many plaintext clients default to 72 to allow room for multiple levels of quoting.


This misses the most annoying part of the line wrapping which is how it interacts with GMail's "Undo Send" feature. If you notice an error in your email and click Undo, they bring you back to the compose mode with the hard newlines still inserted.

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.


This was a problem for me when I had to parse incoming emails. The solution I came up with was to ignore the text/plain part and instead strip all HTML from the text/html part, leaving you with the original text without all of the added newlines.

I wrote about this here: http://adamlafave.com/email-parsing-dont-parse-text-plain/


Yes, plain text e-mail in Gmail is awful, absolutely unusable, fact recognised by many people, e.g. the Linux kernel people[1].

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


The problem with RFC2822 (as with all specifications) is that it failed to correctly predict this future (and ideally all other possible futures).


The good thing about RFC822 (and by extension RFC2822) is that it is extremely flexible instead of trying to predict the future and in the process creating an unimplementable monster of mispredictions (cf. OSI networking stack).

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).


I was being somewhat facetious, but you're correct. It's a balancing act of so many factors, many of which are beyond the originators control or realisation.

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.


It's great to see the old 80-column punched card standard fossilised in these modern environments...


And my understanding is that we got punched cards of that size because they fit into the boxes and drawers for large-format US banknotes:

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?"


Hollerith cards originally had 45 columns.


Line length around 80 columns come from letter paper in a typewriter (via teleprinters) which in turn comes from book printing, where around 60–65 printed characters (plus blanks) were established as most readable centuries ago.


80 columns gives you 3 files side-by-side on a 1920 monitor.


Surely that depends on more than just the number of columns and the number of pixels.


It's not like you can't use a real email client. What's this obsession with web apps for everything? Use thunderbird, or k9 on android.


I've never seriously used anything except a real client for e-mail (ZIMACS, then Thunderbird, then Apple Mail, now mutt), and any time I have used a web-app for e-mail, the whole process is just frustrating. I'm especially surprised when I come across people who say they ``live in their Gmail'' and actually do live in the web-app.


The worse thing is totally different interfaces between different mail providers. It makes impossible to have multiple email addresses and manage them in a sane manner.

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.


Just start it? In the standard config, it has a help line that tells you about all the most common key bindings, I'd think it really isn't difficult to get started and look things up in the manual as needed. If you are not on a fully configured unix system with an MTA and local mail spool, the only thing you'll have to set up to get started should be the mail server config.


Yeah, I need to find the time to just roll with it.


Why you just do not use different email client?


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


(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


To me the 78 line break is still relevant, not because my displays are small, but because wider texts are less readable.


So, 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.


You 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.


That 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.


enter a newline character, tab-in the same number of tabs as the previous line, then add spaces to align.

That method is broken unless we also agree on a tab width, in which case we may as well use spaces anyway.


I suggest you try it. Here is an example file [1]. Try adjusting the tab size: you'll find the arguments are always aligned. I like to set vim's listchars with the UTF-8 light shade and medium shade blocks to make tabs visible. Here are screenshots with ts=4 [2] and with ts=16 [3].

[1] http://sprunge.us/AOGg

[2] http://i5.minus.com/iu14dVi9QRTri.png [3] http://i4.minus.com/itno9LlgJobQD.png


I see the confusion. For aligning function call arguments your strategy works fine. Here are a couple use cases that don't work out so well with tabs (taken from the Jalopy manual [0] to make finding examples easy):

function declaration (most people would accidentally use too many tabs here):

    public void severalParameters(String one, int two, String three,
                                  StringObject four, AnotherObject five) {
        ...
    }
assignments:

    String        text  = "text";
    int           a     = -1;
    History.Entry entry = new History.Entry(text);
Ultimately the problem with mixing spaces and tabs in one document is that programmers are human. Someone will inevitably make a change to the lines you've carefully indented and mess up the whitespace, and someone else will have to go back to fix it in a dummy commit. Having a simple rule that's easy to follow eliminates that source of wasted effort.

[0]: http://jalopy.sourceforge.net/existing/manual.html


The strategy works perfectly fine for those examples.

    	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
    	}
For these assignments, anything to the left is a semantic indentation (tabs), the rest is all alignment (spaces).

    	String        text  = "text";
    	int           a     = -1;
    	History.Entry entry = new History.Entry(text);


Sure, you can make it work. By point is just that you're introducing a burden making people remember which whitespace to use in which context. At that point you're forcing your devs to show non-printable characters in their editor to get it right. You devs are now spending their time checking whitespace instead of writing code, which is lost productivity.

As with any coding standard, the point of the rule is to eliminate such sources of lost productivity.


What 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.


Usually, 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.


That'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/. 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.


The 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.


That'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.


Code and poetry can be formatted with whatever line breaks you want. We're just talking about not putting CRs in the middle of paragraphs.


Really? I thought the article said that lines would be hard-wrapped after 78 characters.


I 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'


i finally gave up and switched to sending html mail precisely because of this issue :(


This post made me remember something: with the mail client which is built-in into Windows Phone, it's impossible to send plain text mails, even when you use Gmail.

And, on top of that, the mails are sent with the Calibri font. (Sorry for the off-topic)


"My answers below, in red."


The author hasn't made a case for why he needs to send plain text emails.

Every mail client - including text mode ones like Pine - supports HTML formatted emails, even if they end up displaying them without formatting.


Most of the emails I send contain no formatting whatsoever, except for indentation, paragraphs and other formatting that can be represented just fine using plain text.

Why should I wastefully send unneeded markup that inflates the size of my email several times larger than what's actually needed?


I don't think that is a very good argument in these modern times, with the relatively huge storage and bandwidth availability. The extra size of such formatting markup is negligible.


Checking my mail archive, the HTML part of multipart messages is on average 5 to 10 times larger than the plaintext part. Such a factor is essentially never irrelevant, even with decently fast connections it often takes me a minute or so to download a day’s worth of e.g. debian-user messages.

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).


This preference is based on the assumption that the extra information conveyed in the HTML part of the email is worthless, which may not be the case.

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.


> which may not be the case.

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.


  > [...] but many people do prefer the extra formatting and
  > layout that a well-constructed HTML email can provide.
I think that's where the issue is --- nearly all HTML e-mail that I encounter is not of the well-constructed variety, and thus doesn't merit the extra overhead.

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.


I've yet to see a "well constructed" HTML email that was sent by a human as part of an email conversation.

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.


Well, in practice, HTML in emails almost never is worth it, and that's not because richer markup is necessarily a bad idea, but because people don't grasp the concepts, and because what plain text provides almost always is actually powerful enough, while being a lot easier to use - which is important, given that emails tend to be read once, in contrast to websites, which tend to be read lots of times, so more effort in composing them is justified.

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.


A lot of mailing lists require you to send plain text emails, with the Linux Kernel being an example.


Don't those mailing lists also require line wrapping?


They require sensible line wrapping. Line wrapping text is good, even required for commit messages, but line wrapping git patches is obviously a catastrophe. On Gmail you can't turn wrapping off (and you can't send patches anyway as it elides leading indentation and changes tabs to spaces).


you beat me to it by a minute ;)


Many mailing lists only accept plaintext. It's a common standard in older communities (ex. linux).


Seems a rather archaic requirement to be imposing on one's users, but thanks for clarifying!


Because plaintext is nice and simple.


The point of the convention is making the text fit on a 80-character fixed-with screen. QP-encoding the text won't solve that problem, as it will only create a very long line that is encoded in a way that has literal line breaks into it, which isn't the point.

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.


I disagree, because it's (far) easier to soft-wrap QP long lines than it is to unwrap hard-wrapped short lines. Hard-wrapping essentially causes a loss of information, by not distinguishing between user-inserted and program-inserted newlines.

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.


Once you insert all the line breaks, the email clients can not reliably reconstruct the original paragraphs anymore.

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.


> 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.

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.
I would probably prefer the latter behaviour on a phone or screen with less than 80 characters, whereas on the desktop, I’d rather not be presented with lines running over the entire width of the screen.

But really, this is pretty standard in mail clients…

Edit: added quotation mark, sorry.


The point of typing a message in a webmail UI and sending it is to deliver the exact message you entered to the recipient. Adding hard line breaks, effectively altering the original message, is not useful.

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.




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: