15 ms·

>…and here it is in neomutt, which helpfully “renders” the HTML with lynx: >… >But that’s a solution born from practice: the fact remains that HTML email does

>…and here it is in neomutt, which helpfully “renders” the HTML with lynx: >… >But that’s a solution born from practice: the fact remains that HTML email doesn’t generally degrade gracefully in clients that don’t support images or CSS. I hope that companies don’t waste their time at such edge cases that are irrelevant for 99.9% of users such as Lynx graceful degradation. It reminds me of the stories about clients that want their website to look nice in IE6.

megous 4y ago
If company can't be bothered to learn how to send email properly, their email will just go to trash, thank you. :) Things like: - sending empty plaintext part or differnt content in plaintext part and html parts within multipart/alternative subparts (https://www.freesoft.org/CIE/RFC/1521/18.htm https://www.freesoft.org/CIE/RFC/1521/18.htm) - pretty much only some automated/marketing email is guilty of this. normal senders always get it right - sending 5 line uncopiable tracking link in plain text (links should be shorter than 80 chars, to not annoy anyone trying to copy paste them) - sending broken html just because it maybe renders some insane table layout in outlook 97 from 50 years ago more "nicely"
r_hoods_ghost 4y ago
Yep. I read this and thought PEBKAC. Optimise for the base case, be inclusive of those using screen readers, ignore the masochists who insist on making life difficult for themselves by refusing to use technologies that have been around for decades. The author's other issue - multiple browser sessions open and logged in to different accounts and tabs opening in the last active one - this is a more common annoyance. But easily solved by the user making sure they are in the right browser session by focussing it. So PEBKAC again.
- woodruffw 4y ago
  I'll say as the PEBKAC'd author: I try to remember to focus the right browser session! But I still load the wrong one about once a week, and whether it works with a particular site is a crapshoot.
gregmac 4y ago
Without weighing in on this, I think this entire section is a distraction in this post. The author's point in this article would be better served by moving the HTML rant to its own blog post.
weird-eye-issue 4y ago
Well there was a time when IE6 compatibility did matter
hericium 4y ago
Multi-part MIME emails with both plain text and HTML content used to be a standard[1] or at least a good and common practice. Not including plain text version or making it "can't see newsletter? click here for web article" is an ongoing process of moving users from unsnoopable email to invigilated web. It's invisible to dumbed-down users, possibly saves corpos some money: devs can learn something that benefits business more and, depending on email volume, business may decrease spending a bit by removing few kilobytes of text from each message sent. Imo a standard of sorts, being removed due to lack of knowledge or for money (savings on data transfer or profit from data gained from users reading "web version of email" and email clients loading remote content) doesn't make it an "edge case". The edge case here (necessity to parse and read HTML in pure email client) is an effect of businesses and developers not following standards in the first place. Also, IE6 overstayed its welcome not due to edge user cases but due to corporate savings as well. [1] https://www.rfc-editor.org/rfc/rfc2046.html#section-5.1 https://www.rfc-editor.org/rfc/rfc2046.html#section-5.1

megous 4y ago

If company can't be bothered to learn how to send email properly, their email will just go to trash, thank you. :) Things like: - sending empty plaintext part or differnt content in plaintext part and html parts within multipart/alternative subparts (https://www.freesoft.org/CIE/RFC/1521/18.htm https://www.freesoft.org/CIE/RFC/1521/18.htm) - pretty much only some automated/marketing email is guilty of this. normal senders always get it right - sending 5 line uncopiable tracking link in plain text (links should be shorter than 80 chars, to not annoy anyone trying to copy paste them) - sending broken html just because it maybe renders some insane table layout in outlook 97 from 50 years ago more "nicely"

r_hoods_ghost 4y ago

Yep. I read this and thought PEBKAC. Optimise for the base case, be inclusive of those using screen readers, ignore the masochists who insist on making life difficult for themselves by refusing to use technologies that have been around for decades. The author's other issue - multiple browser sessions open and logged in to different accounts and tabs opening in the last active one - this is a more common annoyance. But easily solved by the user making sure they are in the right browser session by focussing it. So PEBKAC again.

woodruffw 4y ago
I'll say as the PEBKAC'd author: I try to remember to focus the right browser session! But I still load the wrong one about once a week, and whether it works with a particular site is a crapshoot.

gregmac 4y ago

Without weighing in on this, I think this entire section is a distraction in this post. The author's point in this article would be better served by moving the HTML rant to its own blog post.

weird-eye-issue 4y ago

Well there was a time when IE6 compatibility did matter

hericium 4y ago

Multi-part MIME emails with both plain text and HTML content used to be a standard[1] or at least a good and common practice. Not including plain text version or making it "can't see newsletter? click here for web article" is an ongoing process of moving users from unsnoopable email to invigilated web. It's invisible to dumbed-down users, possibly saves corpos some money: devs can learn something that benefits business more and, depending on email volume, business may decrease spending a bit by removing few kilobytes of text from each message sent. Imo a standard of sorts, being removed due to lack of knowledge or for money (savings on data transfer or profit from data gained from users reading "web version of email" and email clients loading remote content) doesn't make it an "edge case". The edge case here (necessity to parse and read HTML in pure email client) is an effect of businesses and developers not following standards in the first place. Also, IE6 overstayed its welcome not due to edge user cases but due to corporate savings as well. [1] https://www.rfc-editor.org/rfc/rfc2046.html#section-5.1 https://www.rfc-editor.org/rfc/rfc2046.html#section-5.1