Why does email development have to suck? – Explaining all the <tr>'s and <td>'s
dodov.dev
dodov.dev
No, it is not. An email is a text document. That document might be HTML, but it doesn't have to be. And if such email is sent to me, the HTML is never rendered because I don't allow it.
The only time I get HTML through email is when it's spam or commercial email, and screw them. Sometimes a real person will neglect to turn HTML off in their mail client, but even then, they aren't really using HTML or are using it for trivial things, so not allowing HTML only makes the garbage email hard to read.
https://datatracker.ietf.org/doc/html/rfc1341
HTML email is not merely an HTML file sent by email – it is the email.
I'm not sure if the semantic distinction makes sense. An attached file in an email is the also the email. Both HTML, images, and other content types are all sent in the same manner in the body of the email.
This is not the case. In the case of an attachment, the message body is multipart/mixed, where one part is the actual message the sender typed and other parts are the attachments. In the case of an HTML email, the message body is multipart/alternative, where the parts are two or more representations of the actual message typed by the user.
If what you were saying were true, you wouldn’t be able to send an HTML document as an attachment to an email without it being interpreted as the message typed by the user. There is a clear difference between an attachment and the message itself; HTML email is the message itself, not an attachment.
This is not correct. In multipart/mixed you can have any number of body parts with any mixture of content types, including sub nested multipart/mixed body parts. There is nothing that separates a "message" from an "attachment" except for presence of a content disposition header.
> If what you were saying were true, you wouldn’t be able to send an HTML document as an attachment to an email without it being interpreted as the message typed by the user.
Indeed, old email clients may not understand mime formatting formating which is why it is recommended that in a multipart/alternative body you should have the plaintext body part first since the entire body will be displayed.
The only reason why a HTML document, that is a body part of a multipart/mixed message, should not be displayed as part of that message is if it has at content disposition header.
There is no clear difference between "message" and "attachment" in the email format spec. Those two categories come from how email clients represent the presence or absence of a content disposition header.
The the text/html content type was not indeed not explicitly part of the mime type standard, but it was a standard that was explicitly designed to be extensible.
It was intended that subtypes of "text" would be human readable as raw data. If HTML emails aren't human readable without piping into an external program and aren't a multipart/alternative type with the plaintext version first, then it is very reasonable to complain that the sender is doing a bad job.
It’s all text if you split enough hairs.
This part feels like you're being difficult for the sake of being difficult. I agree that presentation >> content for many emails, but stuff like bolding, monospace, and inline images is genuinely useful in emails.
Heaven help any friends/coworkers who tried to send you an email with color, embedded pictures, or bullet point lists.
Another time I needed to provide a summary of options for fees and that got added as a table with colours to indicate fees, profits and losses.
And I don’t care at all if it meant that it could not be read in mutt. At some point we have to march forward or we will never progress at all.
For all communications that matter today, email is 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.
Ironically, this is a reaction to "email is text only!" as stereotypical as the comment you are venting about.
You simply put your own bubble in the center of the universe („all communication that matters“ ... ?!). For example: Our company cares, our whole team cares. My bubble cares. I care. And I think we are running serious business.
We might not be the majority, but when one is just looking at the amounts of mail, even common users are less important then bots.
But I understand many people do not care about because they simply don't have to and/or are not into topic. It „works“. And therefore I'm still not sorting out HTML emails in my inbox or complain when receiving them. But I will not make the problem even bigger and start sending them (so... leading by example at most :-D).
Additionally, I think the article is another proof why HTML emails still is a bad idea although I don't blame people on the streets. Even if it "works". But clearly, there is much text email out there that matters.
> For all communications that matter today, email is HTML.
Ha, thwarted you both!
I only accept and send RTF.
"Why don't you use a mail client from this century." --the IT guy at a former job of mine
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable ------=_Part_4161549_398020174.1685704999675
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit(These emails are not marketing emails which I don't get, they all relate to orders and shipping)
Meaning the 'plain' text is Html-formatted to look plain and there are tracker links and probably tracking pixels too.
Real plain text should be just like something a human being typed.
Also, ignoring the general scamminess of hubspot, the linked article says html mail is MORE likely to be flagged as commercial. The article, in fact, is entirely pro plain text.
And the argument that anything beyond plain text is a waste and ruins everything applies to literally every single medium out there where the written word is conveyed: webpages, magazines, printed flyers, books, etc. It's laughable to think that all formatting of any kind beyond ASCII is a waste.
If it were up to HN readers, the entire world would be so ugly and boring.
And why not in text messages? Its 2023 guys.
>Approximately no one outside of HN only wants text emails.
Approximately no one outside of HN even knows that plain text is a thing distinct from HTML. Among those that do, many probably couldn't give an example from their digital experience of a place where user-submitted content must be plain text. (They can navigate those places just fine, though.)
Basically, I don’t think it’s militantly text-only, it’s just shit.
What HN does, i.e., allow comments to contain a couple of carefully-chosen formatting options, is not a realistic option in email whereas because of a history of decades in which email clients could render only plain text, asking email senders to send plain text is a realistic option at least in some situations.
In other words, HN's designers were not restricted to a choice between plain text and full HTML, but in email we basically are (because there is no central authority in charge of email).
So we keep choosing formats that support the subset of features that our current problem needs. Email multipart messages containing a "safe" subset of HTML has solved some problems adequately, and when it doesn't always work, we include a link to a web page, so you can show it in a real browser, or we attach or embed a PDF.
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.
> Hey ${name},
> Our custom holographic stickers are on for on for ${deal}.
And that’s it. I bet they have awesome deliverability because it’s… just email.
Either your message does have some useful information for the reader, in which case say that and then get out of my way, or it doesn't, in which case you're a spammer. There is no third option.
It's typically a notification in response to an action you initiated on some web application.
https://postmarkapp.com/blog/what-is-transactional-email-and...
2. Yes, abandonment will be higher if the user can’t click the password reset link in the 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.
Personally, I've been using mutt in the terminal as my primary email client for several years, and I absolutely prefer plaintext email.
But this isn't about me. Nor is it about any other computer nerd here clutching their pearls over HTML email. The reality is that users of web applications — the kind that probably a significant proportion of HN readers develop to earn a living — expect HTML transactional email.
It's table stakes. That's just the reality.
But only because the best way to accomplish the first option is to be cognizant of the way the information is presented so that it can be most effectively conveyed. And that can involve paying attention to layout and color and possibly including some graphics.
Virtually all email clients support html since a decade and the expectations user have todays have changed.
To put it differently, it looks unprofessional.
Especially when dealing with technology, consistent branding actually has an important safety factor for consumers.
There is nothing in the average external email that requires HTML or CSS.
There is no useful content in any email that requires JavaScript.
"looks unprofessional" is cultural, and of the same significance as green vs blue text bubbles in your SMS messaging system.
Transactional mail typically requires some hyperlink for the average user.
"If you want to continue with the subscription, reply with the word YES on a line by itself. You can put comments on other lines and we will read them."
do-not-reply@marketing.com is one of the stupid innovations by people who can't automate their email. Transactional email gets handled by robots and fed into a ticketing system when it goes awry.
Treat your customers like customers, not consumers.
Transactional mail is not marketing mail.
It’s not a good look to declare things as stupid when you aren’t sure what the discussion is about.
I’ve worked with a system that let users order domain names by email and it was a nightmare to maintain. Don’t EVER build a system that relies on reading and parsing emails sent by users, it WILL fail horribly.
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.
Maybe they’ll write « yeah » or « YE » or « oui », because that’s what users do
Those users absolutely can write 'YES'. They're perfectly capable of doing so. They don't do so because they're lazy. We all know people that simply refuse to read any kind of instruction on a computer screen. They will skip past any and all prompts. Guess what? That's their problem, not yours.
Stop enabling laziness!
If you can't create a way to say "yes", which is at least as easy to use as checking a checkbox and clicking a button, why should I assume you're capable of, well, much of anything.
It's not that it looks unprofessional. It looks either incompetent, or deliberately obtuse. In either case, I'll take my business elsewhere.
"Yes alright renew my subscription, just make it start in two weeks this time"
Your "solution" fails immediately here, because it gives people a false idea that they are in a dialogue with you whereas they are actually just expected to reply in a binary way.
Finding "a line of text in a string that contains the word 'YES'" is indeed trivial, however if that's all you can think of you should not be employed in any position of responsibility as it demonstrates a profound lack of judgement, understanding of how real people behave, and general business acumen.
The point of a business is to make money. You make more money by making the experience for your customers as easy as possible. If you don't, another company will.
Or worse then, like idiots that cannot understand a simple sentence and write back « YES »
w3c suggests surrounding them with angle brackets [1], but I can't find a source that makes more than a suggestion. By reports, some mail user agents, and some users will include the trailing > in the url they provide to their web user-agent, so that's something to consider and make sure the destination of the link can handle.
Putting links on a line by themselves works well too.
If you don't know what a user prefers, it makes sense to send a text/plain with links as I've described, as well as a text/html with links in tags, because tagged links may be friendlier to some users and some mail user-agents are tragically bad at their job.
Right? Or do I have something wrong?
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.
Furthermore, many emails are direct links to status pages of orders, account verifications, password resets, and so on, which are definitely most functional as a clickable URL.
There is nothing that requires any text to have any formatting. But basic formatting can help readability. There is a reason to include bold or italics. Or headings. Or maybe even a simple diagram/image, or make links more approachable than the raw url.
Snail mail letters can include all of the above (except links), why not email?
Even when written memos were the norm in business, they still had company letter head.
That non-existent third option is critical for good communication.
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 without having to leave their mailbox. Pretty hard to do that in plain text.
So I've adapted to the reality that "email client" is now a web page on a service somewhere, and "email message" is another web page. I don't have to like it, I don't have to use it, but raging against it is a waste of everyone's time.
The problem is the lack of consistency between email clients. It's crazy how each email client has a completely different and crazy idea for how to interpret basic HTML. And heaven help you if you have a brand designer breathing down your neck about dark mode...
If you happen to be starting out with emails, I hope this can get you up to speed with exactly how everything is fucked. And if you're an Outlook survivor, I hope you'll find something you can relate to…
https://github.com/siguelaola/mjmgr
I only really did sendgrid and mailgun, but as a POC it worked well. Just putting this out there because it's useful but I don't touch it much anymore.
People choose the wrong targets for violence.
On the other hand, complex html in emails is mainly for the benefit of the businesses sending you the email, for their commercial purposes, i.e., mostly spam. It rarely has anything to do with communicating useful content to the receiver. If the email is too complex for the client, maybe it shouldn't be in the email.
Or, you know, you could just SEND TEXT.
Can you conceive your needs and your basic understanding of an issue is not, in fact, the whole thing?
…yes, there is. Email is a communication medium, and like in all written communication, an image can be useful. Do I really need to explain that images are useful in human communication?
> and most other people
According to you I guess?
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 6 pages of continuous paper (Long-legged she was.)
Writing this, I wonder what desperate marketing attention whores would produce with ASCII art.
https://email.uplers.com/blog/pixel-art-in-email-design-insp...
Pizza Express made a habit of this for a number of years.
Creating precise multi column responsive designs that work both in outlook and sane email clients is a nightmare.
You may still have to slice images, but it's grid/column support has worked great for me.
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.
And don't get me started on forms.
MJML has been a real shot in the arm from that standpoint, as it greatly simplified what was possible.
1) Use AppScript from google to find those.
2) Save all the links.
3) Go through them manually (because each service will want you to confirm you did not click by mistake).
Looking at my spam folder, how about hitting the unsubscribe link in email from the alias “100_free_spins” sent from top1.povertytrap.site? There’s an unsubscribe button at the bottom.
I’m slightly impressed how that spcammer is using the email “povertytrap” but I assume it’s just by chance they hacked that domain to send spam.
In other words, no shortage of interesting if often maddening problems to work on here.
Then I saw that this was all just about formatting HTML mail.
Oh.
As someone who has done E-Mail Development and worked with Whatsapp, I'm still very much of the opinion that the former is much worse.
Then, use html-to-text from npm to convert that into text.
Then, every email sending service allows you to send text and html based emails. Regardless of the end user preference, it just works.
Only a monopoly like Microsoft could get away with that.
What's the problem there? Unless Microsoft forces you to buy a separate Word license to use their email product, who cares if they reuse some of their own code?
If real competition existed senders would send modern HTML mail using CSS and Outlook would not be able to render half of it. But instead developers have to write email to the antique standards used by Word, with layout using tables and without css.
And Microsoft doesn’t care, they get away because Outlook is the monopoly.
It's good to remember that Outlook isn't actually an email client. It was bought by Microsoft back in the days before TCP/IP became common. Outlook (still) calls messages "memos". The _first_ thing Outlook does with an RFC-compliant email is convert it into the Outlook "memo" format. There is no option to view the original email message at all. Microsoft simply bolted on a filter to deal with emails. I had hoped that the "Mail" client in Windows 10 would be a real mail user agent, but it's _worse_ than Outlook, without the excuse of predating email and being another program MS bought and rebranded.
It's the only way to ensure you're logo is forwarded to every single CC and BCC.
edit I take it all back, gmail strips them. I guess as an attachement and then referenced like <img src="cid:<id>">
https://www.caniemail.com/features/image-base64/
The most reliable method is to attach a png image to the email and reference it from the body using `<img src="cid:insert_cid_ref_here" `
Or you make ASCII art of the logo.
Browsers are actually okay with <style> tags in the <body> and apply the rules inside. Although MDN says they must be placed in the <head> [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...)