[HN Gopher] When the Text and HTML Disagree
___________________________________________________________________
When the Text and HTML Disagree
Author : zdw
Score : 40 points
Date : 2021-01-07 15:32 UTC (7 hours ago)
(HTM) web link (www.solipsys.co.uk)
(TXT) w3m dump (www.solipsys.co.uk)
| egwynn wrote:
| Bulk senders overwhelmingly prioritize html email content
| correctness over plain text correctness. For the past 2 years
| I've been getting monthly emails from a _major_ auto vendor
| financing company whose plaintext part begins:
| Dear < Customer >, This email is a reminder that your
| payment of $< Payment Amount > is due in < Days Prior
| Reminder to Due Date > day(s).
| Shared404 wrote:
| Dunno if the author is on HN, but I just want to say I love the
| design of this site.
| chacha2 wrote:
| You don't even need to look at the site to know what it looks
| like when HN says this.
| Shared404 wrote:
| Thanks for the laugh, and yes, I'm guilty as charged. :)
| psychometry wrote:
| Disagree. There's nothing I hate more than having to downsize
| my browser window because some minimalist didn't restrict the
| characters per line in the body text.
| ColinWright wrote:
| Ping.
|
| Thank you.
| egwynn wrote:
| I think probably not:
| https://www.solipsys.co.uk/new/WithdrawingFromHackerNews.htm...
| ColinWright wrote:
| I was away for a long time, and my usage pattern has changed
| substantially.
|
| But I exist sporadically, with long periods of absence.
| codetrotter wrote:
| From the page you linked:
|
| > I'm not going to stop reading, and I'm probably going to
| make the occasional contribution.
|
| And looking at the history of submissions for the domain of
| the OP article we find that he is still commenting too. Most
| recently about 18 minutes ago in fact. So I think there is a
| good chance that the author will see the comment of the
| person you responded to :)
| codetrotter wrote:
| It's also very cool when they send html and plain text in the
| email, but the plain text just says "your email client does not
| support html, please visit the following link in a browser to
| read".
|
| And by very cool I mean annoying and not cool.
|
| And the reason that it's annoying is because I do have the
| capability of reading both, it's just that because I read my mail
| in mutt I would prefer to read the plain text version instead of
| the one that has been piped through elinks since in an ideal
| world the plain text version would be better formatted for that
| than what I get from elinks.
|
| Unfortunately the world is far from ideal, so you get stuff like
| this instead. And I'm left with the option of dealing with it in
| basically one of a few ways
|
| - Configure mutt to prefer html over plain text, meaning a
| slightly worse experience for mails that are actually better
| formatted in their plain text originals.
|
| - Keep my current configuration and having to press a few extra
| buttons every so often in order to see the html attached version
| instead
|
| - Making a convoluted system that is based either on associating
| preferred format with the sender address, sender mail server etc.
| Or one using heuristics to compare the text and html versions and
| choosing one based on that. Ultimately this either such type of
| system would be time consuming to make and probably fragile
| leading to more frustrations.
|
| - Abandoning mutt. Truth be told mutt is not ideal, and at some
| point I will probably stop using it. But I've been using it for
| years and my setup is at a kind of local optimum, where even
| though there are frustrations with it it is never any one given
| point in time where it is worth the effort of making those sorts
| of changes. Even though in the long run, it would be better.
|
| For a while I was toying with the idea of offering hosted email
| to others as a paid service. If I had say 25 paying customers
| that paid a real premium price then I could spend time on the
| setup and have the time being paid time and making it worth the
| effort. But truth be told I am fearful of doing this because with
| the way that email works it will be almost certain that mails of
| my customers end up wrongly seen as spam by some receiving
| systems. And I don't want my paying customers to experience that
| with a service I provide to them for the kind of price that I
| would have to charge in order to offer hosted mail service in the
| first place.
|
| For the record I would charge $100/month. Which for most people
| is crazy compared to either using a free mail service or paying
| for example Proton Mail but I believe that there exist 25 people
| in the world who earn enough and care about the things I care
| about with regards to email that it would make sense for them to
| pay this price for it, and because these few people would know
| that they are paying that price in return for being hosted by
| someone who only hosts a few people and therefore has time to
| properly provide in-depth customer service. But like I said
| because of the likelihood of mails sent by my server ending in
| spam, it is a no-go IMO.
| Sebb767 wrote:
| > So what do you do when the plain-text and html sections of an
| email disagree? I have no answer to that, it's entirely up to you
| to work out which section has the information you need or want.
|
| I guess the best heuristic is probably to let the HTML section
| take precedence, as a lot of modern clients will display it as
| the default and it is therefore likely to be the tested/correct
| one. Text is usually only used as a fallback.
| userbinator wrote:
| _So what do you do when the plain-text and html sections of an
| email disagree?_
|
| Tell the sender. If no one does, they won't know of this problem.
|
| Of course, sometimes it happens that telling the sender is part
| of a reply to an angry sender who thinks you didn't read the
| email or read it wrong, in which case they will definitely be
| listening.
| frenchy wrote:
| A while ago I worked on a library [1] to help send out
| notifications for a Django site. The notifications could be in
| various forms, but email was the most common. After a few
| prototypes, I quickly realized:
|
| 1. People don't want to bother proof-reading both the HTML & text
| version, so if they're kept separate, people will just update the
| HTML version and the text verison will get stale.
|
| 2. People don't want to learn Markdown (or ReST/etc) to render
| HTML from text.
|
| 3. Even if they did, the result quickly becomes strange and
| difficult to read in-text if you want fancy formatting.
|
| 4. On top of that, templating is troublesome for anything not
| html/text. Escaping requires special support that Django doesn't
| have.
|
| The only effective solutions I could think of are are a) don't
| provide a text version b) automatiatically generate the text
| version from the HTML version. I ended up picking b, and it
| worked okay, though it's still easy to fool it with bad HTML
| (like an image with a non-sensical alt value).
|
| [1] https://pypi.org/project/django-vox/
| leephillips wrote:
| Isn't the obvious solution to only provide a text version? I'd
| rather get an email notification as un-marked-up text.
| jancsika wrote:
| > When code and comments disagree, both are probably wrong.
|
| Here it's worse-- there is a single source of truth copy-pasted
| into two different parts of the message, apparently synchronized
| by forcing a human to remember to do some work to synchronize the
| data.
|
| Even worse, the implicit OR in displaying the data essentially
| guarantees that even someone _trying_ to synchronize the data
| must go to the trouble of viewing both the HTML _and_ the plain
| text to make sure it 's correct.
|
| And perhaps to a layperson, "plain text" means "I checked a test
| message in gmail, there were no images in the message, so I guess
| I just verified the plain text is correct."
|
| This reminds me when I was documenting how an over-engineered UI
| widget works, and I suddenly noticed there were two member fields
| far apart from each other in the struct:
|
| 1. int x_changed
|
| 2. int x_change
|
| Sedimentary Programming ftw! :)
___________________________________________________________________
(page generated 2021-01-07 23:01 UTC)