6 ms·

> The other annoyance I have is with email clients that display plaintext emails in proportional font, which mangles ASCII art diagrams and nicely-aligned table

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

zAy0LfpBZLC8mAC 12y ago
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.
- nailer 12y ago
  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.
  - zAy0LfpBZLC8mAC 12y ago
    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.
    - nailer 12y ago
      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 https://news.ycombinator.com/newsguidelines.html
      - zAy0LfpBZLC8mAC 12y ago
        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.
- exogen 12y ago
  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.
  - zAy0LfpBZLC8mAC 12y ago
    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.)
    - exogen 12y ago
      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.
      - zAy0LfpBZLC8mAC 12y ago
        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.

zAy0LfpBZLC8mAC 12y ago

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.

nailer 12y ago
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.
- zAy0LfpBZLC8mAC 12y ago
  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.
  - nailer 12y ago
    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 https://news.ycombinator.com/newsguidelines.html
    - zAy0LfpBZLC8mAC 12y ago
      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.
exogen 12y ago
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.
- zAy0LfpBZLC8mAC 12y ago
  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.)
  - exogen 12y ago
    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.
    - zAy0LfpBZLC8mAC 12y ago
      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.