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.

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