161–170 of 183 posts
Earlier quoted context omitted.
1. Yes, normal people who don’t read HN have less trust in a plaintext email. 2. Yes, abandonment will be higher if the user can’t click the password reset link in the email.
> less trust in a plaintext email What a remarkable idea! "HTML mail = useless bullshit" is such a strong correlation in my mind that it had never occurred to me other people might see it the opposite way.
Earlier quoted context omitted.
> Now you need to deal with « yes », « Yes », « YES. », HTML wrapping, user signatures, dangling spaces, etc. Oh no, you need to find a line of text in a string that contains the word 'YES'. How incredibly difficult. Are you even a programmer? This is entirely trivial.
My point is you have to trust a user to input some raw text somewhat reliably. Have you dealt with users at scale? Whenever you provide a raw field in a form, the values are pathetic, tons of users can’t input things correct Maybe they’ll write « yeah » or « YE » or « oui », because that’s what users do
Or worse then, like idiots that cannot understand a simple sentence and write back « YES »
Earlier quoted context omitted.
Yes, you can put them in there, but then you're relying on the recipient's client to turn that plaintext url into a link the recipient can actually click on, as opposed to having to copy and paste the url into their browser address bar. Right? Or do I have something wrong?
Yeah, but most email clients do linkify urls in text/plain emails. Heck, an awful lot of email clients linkify urls in text/html emails.
If you send long URLs – for instance password reset links with tokens in them – then you need to send them with an HTML part if you want them to be as reliable as possible. Leaving long URLs at the mercy of not just mail clients but the entire mail transmission apparatus, cannot be relied upon.
Earlier quoted context omitted.
There is no "need" to show logos and images, etc. etc. In fact, far from making things visually appealing, all of that tells me (and most other people) "this is an email which I can safely delete without reading", precisely because real people not trying to sell you something rarely do that.
I believe there is a human need for images, but also that only text is still capable of creating a lot more than you'd expect. When email was monospace text, the whole ASCII art thing was glorious. People added ANSI escape codes and gave us e.g. the glowing, blinking Chernobyl cows, in plain email. I also remember seeing a giant ASCII art 'high-res' nude somewhere, intended to be printed on a matrix printer, on 5 or…
https://email.uplers.com/blog/pixel-art-in-email-design-insp...
Pizza Express made a habit of this for a number of years.
Earlier quoted context omitted.
Once again the stereotypical HN comment of « no this is all wrong, my way is right » For all communications that matter today, email is HTML. No one cares that JohnFen choses to not render them as HTML.
> No one cares that JohnFen choses to not render them as HTML. Many people care. If you aren't including a plain text version of your email, you aren't following email best practices.
Sometimes being the word.
Most corporate email will continue to be HTML for the foreseeable. There's no point expecting it to be anything else, because it just won't be.
As an ABAP developer, I thought "that doesn't sound too bad". I definitely need to get out of there before my brain rots further. And for anyone curious: https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-us/a... Those are the keywords, about a third of that list is obsolete and you usually need multiple of them to make a valid statement. And that's just the tip of the iceberg.
I love how the numbers 1 to 7 are keywords and 8 and 9 aren't.
It's HN, so I'm not surprised by the old "just send text" argument that always gets wheeled out when this topic come up, but for those not in a terminal all day there are valid reasons to format HTML emails (that don't include marketing). We send out HTML emails and reports to our users that make use of progress bars, lists, photos, colours etc and they love them. They can get quick full updates on their business wit…
Why don't you send PDFs?
Earlier quoted context omitted.
It's more funny than that. Everyone wants text documents as well as rich documents as well as applications but no one wants a single file type to do all 3.
They totally do, but there is no single file type which supports all the formatting you might occasionally want, like math or floating text boxes or images, at least no format short of PDF. And which is editable, quotable (important for email, even Gmail keeps messing up quoting parts of numbered lists), efficient, implementable, and not a security liability. So we keep choosing formats that support the subset of fea…
As we cant blame anyone specific, I would have to conclude we did everything wrong and had very poor excuses for it.
A complete embarrassment. I find it rather entertaining but offer no solution.
It's HN, so I'm not surprised by the old "just send text" argument that always gets wheeled out when this topic come up, but for those not in a terminal all day there are valid reasons to format HTML emails (that don't include marketing). We send out HTML emails and reports to our users that make use of progress bars, lists, photos, colours etc and they love them. They can get quick full updates on their business wit…
Why don't you send PDFs?
Earlier quoted context omitted.
That's why I said "if you could". I know it's not valid HTML. For some reason, style tags are only allowed inside the . My point was that I find it strange that HTML in general has this limit and that script tags are allowed in the as well.
I had missed the "if you could" part, sorry. Browsers are actually okay with tags in the and apply the rules inside. Although MDN says they must be placed in the [1]. Email clients seem to be a lot more restrictive, apparently. Or lazy. [1]( https://developer.mozilla.org/en-US/docs/Web/HTML/Element/st... )