Why does email development have to suck? – Explaining all the 's and 's(dodov.dev)
dodov.dev
Why does email development have to suck? – Explaining all the 's and 's
https://dodov.dev/blog/why-does-email-development-have-to-suck
180 コメント
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.
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.
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.
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.
Whast about text messages? We must have HTML in text message too, I think, so that we can use them more effectively.
> 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.
Many people care. If you aren't including a plain text version of your email, you aren't following email best practices.
If people care it's not because of an RFC from 30 years ago, it's because marketers have recently started to notice that plain text can sometimes cut through in a way that HTML doesn't.
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.
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.
>> An email is a text document ... the HTML is never rendered because I don't allow it.
> For all communications that matter today, email is HTML.
Ha, thwarted you both!
I only accept and send RTF.
> For all communications that matter today, email is HTML.
Ha, thwarted you both!
I only accept and send RTF.
> The only time I get HTML through email is when it's spam or commercial email, and screw them.
Heaven help any friends/coworkers who tried to send you an email with color, embedded pictures, or bullet point lists.
Heaven help any friends/coworkers who tried to send you an email with color, embedded pictures, or bullet point lists.
You will hate me then. I have recently started to embrace html emails. I needed to book a room for a series of events and color highlightinged the available options.
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.
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.
This all comes back to the question of if we consider new to be progress.
I agree with the OP - it's not misleading to say an email is "essentially" HTML, regardless of whether the client supports parsing out the markup. Browsers too will happily render an HTML file consisting only of the string "hello world", and yet it's still a web page.
I assume your preferred browser is lynx, or maybe you just pipe curl into emacs?
I use mutt and unfortunately in the corporate world you can't just ignore HTML or even HTML only mails. I pipe them to elinks, works 99.9% of the time easily.
That may be the case, but that still doesn't make HTML a part of email itself. It's using email to send/receive HTML.
The ability to use formats other than plain text have been a standard part of email since 1992:
https://datatracker.ietf.org/doc/html/rfc1341
HTML email is not merely an HTML file sent by email – it is the email.
https://datatracker.ietf.org/doc/html/rfc1341
HTML email is not merely an HTML file sent by email – it is the email.
> 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.
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.
> 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 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.
> 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.
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.
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.
This is a tautology. What does the T in HTML stand for?
It’s all text if you split enough hairs.
It’s all text if you split enough hairs.
Umm, no? I don't understand your point...
> And if such email is sent to me, the HTML is never rendered because I don't allow it.
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.
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.
> No, it is not. An email is a text document.
"Why don't you use a mail client from this century." --the IT guy at a former job of mine
"Why don't you use a mail client from this century." --the IT guy at a former job of mine
Text. Just use damn text. Nobody wants to look at your logo. Why biz people have to ruin everything.
Approximately no one outside of HN only wants text emails.
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 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.
I love how there are thousands of internet forums, but you're a heavy participant on a forum that is so militantly text-only that emoji are silently removed from user-submitted content. It's almost like the policy you are arguing against has important effects on conversation quality that you don't understand or that you don't want to admit because your paycheck depends on email messages' being rendered as HTML.
>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.)
>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.)
Given how long dang has been claiming that someday we won’t have pagination and everything will be fast, I’m guessing whatever arc garbage runs HN just couldn’t handle emoji 17 years ago or whatever and that’s what we are stuck with.
Basically, I don’t think it’s militantly text-only, it’s just shit.
Basically, I don’t think it’s militantly text-only, it’s just shit.
[deleted](1)
This link aggregator (it isn't a forum) would be shit if it allowed emoji.
You literally just used italic formatting in your own reply
[deleted]
It's good to be vigilant against hypocrisy, but there is such a thing as being too focused on possible hypocrisy.
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).
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).
Agreed. If things look good then I enjoy looking at them more, and life is to be enjoyed. But more importantly, it's wrong that plain text is always the best way to communicate. A picture is worth a thousand words (often), and a good layout can make things easier to read.
Ultimately it depends on if it facilities the delivery of information. In most cases excessive styling does the opposite.
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 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.
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.
It gets quite hilarious when we take the design goals, technological difficulties both foreseen and experienced, insights picked up, compare the "end" results with the goals and then compare the excuses with what should have been possible technically.
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.
https://bugzilla.mozilla.org/show_bug.cgi?id=19258
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.
https://bugzilla.mozilla.org/show_bug.cgi?id=19258
If only it was a simple logo. My HRs send emails with a full blown wallpaper on top, which stretches the inbox on a smaller screen so much that horizontal scroll appears, and text below it also overflows. Or when I disabple dynamic content, then they manage to create links inside the graphical buttons with no alt text, invisible without the picture. And these are people whose main job are emails. Sigh...
Sticker Mule sends marketing newsletter emails in plain text ONLY. I love it. They’re just:
> 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.
> 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.
Ironically, plain text emails actually do better for us - the problem is that plaintext emails are often more likely to be caught up by spam filters.
The data I've seen suggests the opposite?
All of our internal tests have confirmed this, and even the email providers have more or less confirmed the same thing: https://blog.hubspot.com/marketing/plain-text-vs-html-emails...
That's HTML emails _pretending_ to be plain text.
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.
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.
I'm pleasantly surprised that amazon actually sends plain text emails. Pretty much every other corporation insists on HTML mails.
I just checked, and they don't. It's certainly plain looking and without fancy styling/formatting, but they do send content-type text/html. The links and tracking pixel images are why they need HTML, I guess.
There's an account setting somewhere to always send plain text emails and do not send HTML. I don't know where the setting is, I enabled it many years ago. Been happy with that.
This appears to be untrue. I looked at all the amazon emails in my inbox and they are all:
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printableDid you actually scroll through all the way? Some emails send both plain text and HTML. I looked through mine and indeed saw text/html for most Amazon emails (including AWS). Some AWS emails like ACM cert renewals were text/plain. Though like someone else said here, you may have changed a setting in your account preferences. The default is still HTML.
------=_Part_4161549_398020174.1685704999675
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bitI have zero html attachments.
(These emails are not marketing emails which I don't get, they all relate to orders and shipping)
(These emails are not marketing emails which I don't get, they all relate to orders and shipping)
They aren’t talking about HTML attachments. HTML email is typically sent as a multipart/alternative email with one text/plain component and one text/html component. An email with attachments is a multipart/mixed email.
Mine have the text/plain header. I must have checked that setting like the sibling commenter said.
Tracking pixel in an email? I thought nobody had done that in decades because major webmail clients pre-cache all images to prevent leaking user IP etc.
I don't know about decades. It's true that a lot of clients do that nowadays, but they're definitely still used.
Email is capable of having both versions of the email so the user can decide what they want. We should go back to utilizing that more.
The clients also need to focus on this. Apple Mail on iOS uses plain text variant to show snippets, but if you try to expand the email, it only supports HTML, without a fallback to plain text. This is often the case on slow internet.
That isn’t true: Apple Mail is perfectly capable of showing plain-text-only messages.
The post you're responding to probably meant in the event of alternative HTML+text emails. Obviously if the email is plain text-only it won't invent HTML to show the user...
Nobody outside a tech cave wants to lose all the rich formatting in communication either
I don't understand the insistence on building "beautiful" emails. I'm not the kind of person to insist on text-only e-mail, but I do think it's ridiculous to spend lots of time and money making e-mails that look like fully-fledged Web documents.
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.
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.
Perhaps that is your response, but it’s not true of everybody. I’ve done a lot of experiments with different types of email, and beautiful emails always get significantly better response rates.
Ah. I think the difference is that when I send emails, I do so to communicate information, rather than to elicit people to buy a product.
Even when communicating important information, using the company design has been the norm since graphic printing was invented. Even something as transactional as a bank statement or court summon will use the sending organization's logo, fonts and colors.
Are you relying on the user's email client to convert plaintext URIs into interactive hyperlinks in transactional mail?
No. As I said, I'm not advocating for plain text only emails, just simple ones.
Beautiful emails are easy. Emails with well conveyed and informative text- much much harder.
So, spam.
Is transactional email spam?
Well, that depends. Is it something I need to see? Did I proactively ask for it, or did I neglect to opt out? Etc, etc. If you are having to measure response rate, and it doesn't involve an emergency alert or some such, it is probably spam.
Transactional mail is not marketing mail.
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...
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...
OK. So what, I'm not going to complete my password reset notification because the page isn't beautiful? If you are tracking response rates it is because people aren't expecting an email, because they didn't ask for one (i.e. it isn't a password reset notification). GP is right - I want information I /need/ to be in an email in a succinct format, and I don't want emails I don't need.
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.
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.
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.
I can't tell if this is sarcasm.
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.
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.
Not sarcasm at all.
That's certainly why you aren't good fishing candidate like many people ;-)
How much sense does it make to measure and discuss response rates for transactional mails though?
Low response rates are used as a spam signal by major email providers, whatever the type of email.
How does that make any sense when those are often sent from no-reply addresses that are routed nowhere?
I think response rate is meant more generally in this context. It doesn't necessarily literally mean an email in response. I think more typically it means the recipient following the call to action link in the email.
There's no chance a business today can work with plain text documents at scale.
Virtually all email clients support html since a decade and the expectations user have todays have changed.
To put it differently, it looks unprofessional.
Virtually all email clients support html since a decade and the expectations user have todays have changed.
To put it differently, it looks unprofessional.
There is nothing in the average internal email that requires HTML, much less CSS.
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.
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.
This is an absurdly wrong, yet characteristically HN take.
Transactional mail typically requires some hyperlink for the average user.
Transactional mail typically requires some hyperlink for the average user.
No, it doesn't. Email is a great feedback medium.
"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."
[email protected] 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.
"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."
[email protected] 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.
Now you need to deal with « yes », « Yes », « YES. », HTML wrapping, user signatures, dangling spaces, etc.
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.
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.
> 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.
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
Maybe they’ll write « yeah » or « YE » or « oui », because that’s what users do
As previously written: Treat your customers like customers, not consumers.
Or worse then, like idiots that cannot understand a simple sentence and write back « YES »
Or worse then, like idiots that cannot understand a simple sentence and write back « YES »
If the user can't follow basic instructions then they'll have to try again.
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!
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!
Some businesses like to retain users, and not alienate them using obscure, hard-to use-user interfaces, and blaming the user when they get it wrong.
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.
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.
If you can't reply to an email with 'YES' then you certainly aren't smart enough to have a good enough job to pay any reasonable amount of money.
> 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.
"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.
"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.
How condescending can a single software system be..? A reality check might help. Most of us write applications used not by nerds, but ordinary human beings. They don’t want to perform weird ritualistic dances just so the computer does beep-bop - ”I understood what your intention was just fine, but do it right for me!“.
Have you ever worked with the general public? At least half of adults would fail at that basic task.
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.
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.
Transactional emails are things like reset password emails. You’re really going to build your reset password functionality by having people email their new password to you?
Why would transactional mail come from [email protected]?
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.
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.
You can certainly put urls into a text/plain email. It helps if your urls aren't terribly long and don't have characters that are questionable in urls.
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.
[1] https://www.w3.org/Addressing/URL/5.1_Wrappers.html
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.
[1] https://www.w3.org/Addressing/URL/5.1_Wrappers.html
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?
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.
All the mail clients I use support this, including URLs that wrap onto new lines. Yet I still receive some emails with broken links if they wrap onto new lines. Somewhere along the way, these break before getting to my mail client. I never experience this with HTML email.
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.
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.
Why stop at just supporting the yhe average email though? Tables/embedded images/hyperlinks can be very useful for communication. I can send them without having to worry about platforms/software/SharePoint etc. It is by far the most reliable way of sending a simple, interoperable document we have. And you can easily refer back to it later. There is no good reason not to use html for communication between actual people.
Some people want marketing emails. Did you know some people sign up for them voluntarily? They're like newsletters of old, but electronic. And it arrives in your mailbox, ready to be rendered!
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.
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.
Any formatting in email is html.
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.
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.
To add to this, plaintext emails are a much bigger avenue for phishing, MITM attacks, and scammers.
Especially when dealing with technology, consistent branding actually has an important safety factor for consumers.
Especially when dealing with technology, consistent branding actually has an important safety factor for consumers.
[deleted]
It's weird that your can't conceive of useful information that benefits from HTML elements (images, actual tables, links) and layout design to make it more readable. In pretty much the same way a web page does. I benefit from this as the reader. I want it.
That non-existent third option is critical for good communication.
That non-existent third option is critical for good communication.
>There is no third option
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.
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.
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 without having to leave their mailbox. Pretty hard to do that in plain text.
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.
I am a "just send text" guy. But you are correct; users like HTML and no one, like the author of this blog post, even remember that Internet messages are all plain 7-bit ASCII. I don't mind the HTML as much as I mind the Javascript inside them, or the web bugs that are included. Those are privacy and security issues.
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.
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.
Why don't you send PDFs?
The faster you get to what a user wants or has to review in an email, the more likely they’ll read it.
I read a lot of email on mobile, and PDFs on mobile are a terrible experience. If I see a PDF attachment in an email, I don't even bother opening it unless it's something I was expecting.
Fair point, and we do generate PDFs elsewhere for similar reports but the general feedback from users is that they want to have the data available directly in the email.
As someone who is very familiar with designing and developing emails, I think it's actually a pretty happy medium between format and freedom. Not everything needs to be a responsive, javascript-riddled design with interactivity. 600px-wide text with graphics does the job. (The irony is that often plaintext emails perform better)
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...
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...
When I first got introduced to email development, I remember I wanted to throw myself off a cliff. I couldn't believe how nonsensical everything was. I kept track of everything in a little text document, which I've now turned into a post.
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…
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…
If you were thinking more clearly, you would want to throw whoever asked for "email development" off a cliff.
People choose the wrong targets for violence.
People choose the wrong targets for violence.
Since you mention MJML: I wrote a little tool called mjmgr which was meant to be a prototype of a MJML email manager for a bunch of providers. So that you can keep the source code of the MJML email checked in, but deploy it as compiled templates across various email template providers.
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.
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.
This is cool! My CMS (Craft CMS) has an MJML plugin as well as some good inlining plugins, making it possible to build emails using the CMS as the base. My goal was to have a system that put email templating on equal ground to content display, and MJML was a really key part of that. Love seeing the cool ideas MJML has inspired in the ecosystem.
For the most part you can kind of have header and a footer which you reuse across all email and then just more or less text in the middle. Maybe an image every once in a while. If you can get business partners to agree to that I've found that to be an ideal middle ground.
I am involved in ebook production, so I can somewhat sympathize, in that ebook reading systems tend to be way behind browsers in what code they support.
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.
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.
"So if you want a reasonable portion of users to see your email as intended, let's say 95%, you have to stick to the most basic features of HTML and CSS..."
Or, you know, you could just SEND TEXT.
Or, you know, you could just SEND TEXT.
Wow so clever. That totally solves the need to show logos and images, colors, formatting, centering things, making things visually appealing, etc.
Can you conceive your needs and your basic understanding of an issue is not, in fact, the whole thing?
Can you conceive your needs and your basic understanding of an issue is not, in fact, the whole thing?
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.
> There is no "need" to show logos and images, etc.
…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?
…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?
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 6 pages of continuous paper (Long-legged she was.)
Writing this, I wonder what desperate marketing attention whores would produce with ASCII art.
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.
You might find this amusing:
https://email.uplers.com/blog/pixel-art-in-email-design-insp...
Pizza Express made a habit of this for a number of years.
https://email.uplers.com/blog/pixel-art-in-email-design-insp...
Pizza Express made a habit of this for a number of years.
Last time I had to deal with emails, I've used https://mjml.io/ and was very happy with it. You can version the templates, compile them as part of your build pipeline and it seems to do produce very _adequate_ HTML full of tables that looks good on all clients that we tested.
How’s responsive design with mjml?
Creating precise multi column responsive designs that work both in outlook and sane email clients is a nightmare.
Creating precise multi column responsive designs that work both in outlook and sane email clients is a nightmare.
I've been using MJML for a few years now, I can't imagine even trying to build a responsive email without it. I don't even have to think about it.
You may still have to slice images, but it's grid/column support has worked great for me.
You may still have to slice images, but it's grid/column support has worked great for me.
Does it support things like rounded buttons in outlook? (Require use vml with hard-coded widths)
Doesn't seem to be able to automatically embed images as data urls though. That would be very very nice. Or perhaps it does and I just missed it myself?
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 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.
Hah, that takes me back!! MY first internship was at SAP and I foolishly didn't even ask which technologies I would work with... ABAP is literally the worst lol. This was 2018 btw
At SAP, you get to use all the latest features and are free to change basically anything. On the customer/consulting side, we get to work around terrible ancient standard implementations and our products need to work on old systems, so 700 syntax it is.
And don't get me started on forms.
And don't get me started on forms.
That's why I never saw any SAP job paying peanuts...
As someone who has custom-coded newsletters over the years, I understand the other comments here, but to me, email deserves to have room as a creative medium with visual elements, because visuals are often part of the storytelling.
MJML has been a real shot in the arm from that standpoint, as it greatly simplified what was possible.
MJML has been a real shot in the arm from that standpoint, as it greatly simplified what was possible.
How do I make gmail automatically scan every incoming email for "unsubscribe" links and click them?
So when [email protected] sends you an email that consists of nonsense text, a sketchy link, and an unsubscribe link you want to automatically follow the unsubscribe link?
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.
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.
You can't get the end result by automation alone but you could automate half of it.
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).
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).
Virus scanners and other tools like google will fetch any urls in emails to check their target. So having a direct unsubscribe action behind GET of a link breaks your email list as Gmail will unsubscribe everyone
There must be some additional logic behind that, because I see this regularly behind GET requests and I'm not being unsubscribed from everything.
Is this why they always have a confirm button? That's been a pet-peeve annoyance of mine.
It’s a basic part of HTTP. If you follow a link, that’s a GET request. GET requests are supposed to be safe. A user may not have initiated the action if it’s a GET. If you want something that implies “yes, the user made an intentional choice to take action”, then use another verb, like POST.
Alternatively, make a filter that applies a label and skips inbox. Occasionally, open the label, select all, and Report Spam.
I read the first paragraph and it seemed about right to me: there are many standards at play and many implementations of varying quality; lots of folklore, possibly false, makes the rounds and some of the more important providers are, by reputation at least, known to be difficult; one has to deal with issues of scale and stability and atomicity and reliability; there's 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.
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.
If you think sending email is hard, you haven't tried sending whatsapp messages.
You mean using the godawful Facebook API or one of the unofficial Whatsapp-Web based APIs?
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.
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.
It’s slowly getting better though. I start receiving emails in nmh that can’t even try to display before I delete them.
<tr> and <td> are just hipster flexboxes.
The solution is to use maizzle. It's awesome and has a dev mode where you can preview emails as you write them. It's all tailwind and a great authoring experience.
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.
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.
The answer is, because Outlook is rendering your emails using Word as a browser.
Only a monopoly like Microsoft could get away with that.
Only a monopoly like Microsoft could get away with that.
Well, that explains why, when I try to paste text into an Outlook email, I get an error "there's a problem with Word". (Then you hit Enter and paste again, which works fine.)
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 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.
> 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?
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?
Because they are a monopoly, they get to ignore the HTML standards and set the defacto standard which is the subpar rendering of Word as an HTML browser.
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.
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.
While we are at it, what is the most surefire way to include images into email? How do I make sure that simple images, like logos, are shown in most common email clients?
You don't. Common email clients block images by default, because advertisers used them for tracking.
Or you make ASCII art of the logo.
Or you make ASCII art of the logo.
Or you include a base64-encoded version of the image. Doing it in-line in HTML should work; I believe <img> tags can also reference an email attachment containing the image (email attachments are base64-encoded anyway...).
base64 encoded <img src"<base64>">...
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>">
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>">
Gmail does not support base64 images according to caniemail
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" `
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" `
If the answer isn't "Microsoft Outlook" I will be very surprised.
Just in the last year, I have sent over 30 million emails to our users. Mostly plain text. The last two emails, to the list with over 400k subs, were sent using MJML. Anecdotally OR dropped ~3-5 points. OR avg on the above numbers was 33%, rarely dropping below 30%. Now was 30% in both cases, but it took longer to get to that (I suppose the cause of email filters introducing some delay). Also, our links in the email received spikes of traffic (email spam software running crazy over them). Also, I've got some replies from happy users on how nice the new emails are. I yet have to see what to conclude. TLDR just use MJML.
Wouldn't most of these pains go away if you simply could include style tags (not attributes) in the body? I've always wondered why it's possible to include script tags pretty much everywhere but not style tags.
Nope, that doesn't work as well. I tested it before finishing up the article a few days ago. If you put `<style>` in the `<body>`, it gets removed when the email is forwarded and it still looks like shit.
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 <head/>. My point was that I find it strange that HTML in general has this limit and that script tags are allowed in the <body/> as well.
I had missed the "if you could" part, sorry.
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...)
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...)
Huh, I didn't know browsers are behaving this way these days. I believe I tried this several years ago and it didn't work. Or did I just read the standard? I'm not sure. Anyway, I always assumed it wouldn't work.
100% recognizable
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.