> An email is essentially just an HTML document, like a web page, except it's visualized in an email client, rather than a web browser. However, both are capable of rendering, which is the process of turning HTML code into text, rectangles, and images, i.e. the visualization of the content.
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.
> 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.
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.
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.
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 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.
> 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.
> 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.
> 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.
> 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.
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.
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.)
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.
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).
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.
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.
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.
Why doesn't HN or reddit or most social media format messages in html like email? Email has been doing it for years. People would love it! Images, colors, tables, etc in every message!
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...
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 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.
Did 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.
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.
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.
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.
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...
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.
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.
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.
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.
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.
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.
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.
"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.
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.
> 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
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.
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.
> 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.
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.
If someone wants to unsubscribe, that's probably because they don't want to be your customer any more anyway. Unsubscribing for a now-irrelevant-to-them e-mail list may be a problem for these ex-customers, but it isn't yours any more.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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...
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…
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.
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.
"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..."
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?
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.
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.
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.
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.
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.
So when provide.autoinsurance@fhsbsh.com 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.
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
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.
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.
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.
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.
> 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?
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.
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?
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...).
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.
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.
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.
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.