3 ms·

The more time spent on optimizing for one email client, the less time spent on optimizing for an other. Hands up if you (like me) have skipped coding the text/

by sly010 9y ago

The more time spent on optimizing for one email client, the less time spent on optimizing for an other. Hands up if you (like me) have skipped coding the text/plain part of an email template and sent out multipart emails with no or empty text/plain. Developers are lazy, but business minded people will push amphtml because they think it's an edge. If it becomes a thing, people will create webpages instead of emails and skip proper testing. (Again, myself probably included).

yenoham 9y ago
I co-founded a business, specifically around email testing, largely for the reason you mentioned. When developing we often skipped things like plain text, and usually only did a cursory glance over other aspects, very much less did we automate anything. It came back to bite us so many times (presumably countless times that we weren't alerted too also). Obviously I'm entirely biased, but to your point on business-minds pushing for edge I'm even more convinced that manual testing alone is never going to cut it going forward. Shameless plug at the bottom as it's rare that email testing gets limelight on HN :) https://mailosaur.com https://mailosaur.com
craigds 9y ago
We've done the opposite. After ten years in operation we've only just begun to add html parts to our emails. Its just easier to render plain text, and no one has the time to be spending hours templating and testing emails, we've got better things to do.
- chrismorgan 9y ago
  And the really amusing aspect of that is that text-focused emails (be they text/plain or deliberately simple and barely styled text/html) tend to get better engagement than fancy branded emails—the data I’ve seen from a variety of sources is quite conclusive about that. I wish more people published data about it.
  - Flimm 9y ago
    I like everything about plain text emails except for hard wrapping, which looks awful on screens that are too small or too wide.
    - chrismorgan 9y ago
      To a large extent, hard wrapping is a combination of choices made by the sender (to hard wrap the text, because it doesn’t trust clients to soft-wrap properly) and receiver (to soft-wrap or not). There was a standard to handle it nicely, format=flowed; sadly, it didn’t make it: https://blog.fastmail.com/2016/12/17/format-flowed/ https://blog.fastmail.com/2016/12/17/format-flowed/ But even without that, the quoted-printable content-transfer-encoding means that the hard wrapping isn’t actually necessary—you can have lines as long as you like. Some email clients do thereby send text/plain with arbitrarily long lines, which will cause overflow in some clients (typically where plain text is shown in a monospace font), and be wrapped in others (most, these days, I think; these are typically where plain text is shown in a proportional font). Then too, some email clients ignore the 78 character limit (it is, after all, only a SHOULD [1]) and write longer lines in the MIME message. (Not sure what they do after 998, which the spec says they MUST not exceed [1].) But the inability to specify the desired semantics of proportional-with-wrapping versus monospace is probably the part of text/plain email that makes me saddest. [1]: https://tools.ietf.org/html/rfc5322#section-2.1.1 https://tools.ietf.org/html/rfc5322#section-2.1.1

by sly010 9y ago

yenoham 9y ago

I co-founded a business, specifically around email testing, largely for the reason you mentioned. When developing we often skipped things like plain text, and usually only did a cursory glance over other aspects, very much less did we automate anything. It came back to bite us so many times (presumably countless times that we weren't alerted too also). Obviously I'm entirely biased, but to your point on business-minds pushing for edge I'm even more convinced that manual testing alone is never going to cut it going forward. Shameless plug at the bottom as it's rare that email testing gets limelight on HN :) https://mailosaur.com https://mailosaur.com

craigds 9y ago

We've done the opposite. After ten years in operation we've only just begun to add html parts to our emails. Its just easier to render plain text, and no one has the time to be spending hours templating and testing emails, we've got better things to do.

chrismorgan 9y ago
And the really amusing aspect of that is that text-focused emails (be they text/plain or deliberately simple and barely styled text/html) tend to get better engagement than fancy branded emails—the data I’ve seen from a variety of sources is quite conclusive about that. I wish more people published data about it.
- Flimm 9y ago
  I like everything about plain text emails except for hard wrapping, which looks awful on screens that are too small or too wide.
  - chrismorgan 9y ago
    To a large extent, hard wrapping is a combination of choices made by the sender (to hard wrap the text, because it doesn’t trust clients to soft-wrap properly) and receiver (to soft-wrap or not). There was a standard to handle it nicely, format=flowed; sadly, it didn’t make it: https://blog.fastmail.com/2016/12/17/format-flowed/ https://blog.fastmail.com/2016/12/17/format-flowed/ But even without that, the quoted-printable content-transfer-encoding means that the hard wrapping isn’t actually necessary—you can have lines as long as you like. Some email clients do thereby send text/plain with arbitrarily long lines, which will cause overflow in some clients (typically where plain text is shown in a monospace font), and be wrapped in others (most, these days, I think; these are typically where plain text is shown in a proportional font). Then too, some email clients ignore the 78 character limit (it is, after all, only a SHOULD [1]) and write longer lines in the MIME message. (Not sure what they do after 998, which the spec says they MUST not exceed [1].) But the inability to specify the desired semantics of proportional-with-wrapping versus monospace is probably the part of text/plain email that makes me saddest. [1]: https://tools.ietf.org/html/rfc5322#section-2.1.1 https://tools.ietf.org/html/rfc5322#section-2.1.1