The problem with AMP email mentioned in the article is that it just appeared because someone on the gmail team wanted it. There was no process for getting it out, GMail as the dominant email provider strongarmed a few other providers into supporting it. All questions and discussions on AMP's github were shut down by the project leadership that would go on to write propganda pieces on how AMP development was open to everyone.
Just because there's some marginal benefit to AMP for Email, it doesn't make it good.
Style whatever you like however you like, but please do include a functional text/plain part in your multipart/alternative email, and please ensure it includes all the requisite information and links and URLs that the HTML version does.
I regularly encounter HTML email that has an empty text/plain part, or an error message, or a converted text version of an email that's missing the most critical information. For instance, I often get "confirm your registration/email" emails whose text/plain parts leave out the confirmation link or confirmation code.
Html email is a pox. I set my email clients to use RTF as it’s simpler, more consistent, and one doesn’t send huge email messages full of utterly useless crap (otherwise known as html tags and stuff). I’ve been using email for 40 years and has been perennially a problem of inconsistent email rendering since html became a format option.
It was however a highly reliable and simple indicator of spam and junk.
IF format = HTML then isJunk.
Nowadays with the mindless guzzling at the web junk firehose html email is now ubiquitous and consistent in rendering it seems. But With no improvement in copy or relevance. But it does have bling!
> I set my email clients to use RTF as it’s simpler, more consistent, and one doesn’t send huge email messages full of utterly useless crap (otherwise known as html tags and stuff)
Having written an RTF WYSIWYG editor back in the late 90s, I very much disagree that RTF is any better than HTML for any reasons you’ve cited.
It’s still an ASCII encoded format with font tags and alike. It just opts for curly braces instead of triangle brackets.
The problem with HTML emails isn’t the HTML specification. It’s that
1. Half of email clients don’t support that specification correctly.
2. People abused HTML in emails
However those two points could be just as equally relevant had RTF became the dominant document mark up for the web.
People need very large red "click here" call-to-action buttons to click inside emails. With plain text email you can't have those. Also people need a sampling of your latest blog posts in a table inside all your emails, with a stock photo in the left column and the article title and snippet in the right column.
Prior to computers most business correspondence would be typewritten in essentially the same font with little or no graphics, maybe a logo on the letterhead if you’re really fancy. That seemed to work fine.
Underlining will use much more space with dashes. So much so that the spacing adds to the emphasis. And you can't use it in running text. Underlining with underscores OTOH is hard to read and has less emphasis than normal underlining.
Alignment can be done more or less correctly, but it is a hassle. And it requires a monospace font, which isn't great for readability.
Tables also require a monospace font, and are also a hassle, and you'll still end up with a hard to read pseudo-table.
And that's just the mentioned limitations. You also can't include charts, formulas, screenshots, links, superscript, subscript, italics, without severe limitations.
If email were still limited to plain text + attachments, I think a lot of them would be "please see attached Word file".
These market share numbers cannot be right, can they? iPhones represent maybe 20% of smartphones in use, and Macs are maybe 15% of all desktops. There's no way that Apple Mail has 60% of the email market.
I think what is happening is that Apple Mail prefetches all images when the email is received (over a privacy-preserving proxy). So the Apple Mail users show up as opening every single email, which also artificially boosts their market share.
For most other clients, not only does the user need to open the email but they also need to allow images to be shown for that sender. This will artificially deflate both open rates and market share.
Doesn’t leak your IP address. It also doesn’t tell the server you opened the email, or when you opened it, because it always fetched them whether you open or not.
Basically all the server learns is that the email address went to an Apple Mail client.
Depends on your market/country. In the US for young people, iPhones make up 87% currently.
The global average is mostly dictated by whatever India and China use which is low budget androids. But for sending emails, you are often sending to specific countries only.
Android is dominant in pretty much the entire world except for the US and Canada (maybe some European counties too). Dollars are expensive, and iPhones are priced in dollars. Plus, iMessage is a must have in the US but nobody cares about it outside of the US. I have more digits than iMessages I have sent in my lifetime.
Your immediate and slightly extended circle doesn’t equate to the entire planet. In the UK for instance, it’s closer to 50/50.
Also, much like Windows on the desktop, the email side of things is going to be skewed by business use; I would wager (without the data to hand) that iPhone and iOS is dominant in business, due to the perceived notion of better security and similarity across devices. Though the majority of mailflow globally is spam, or at least greymail, business email outweighs personal use of email. It’s also likely that the majority of Android handsets are merely used as dumb-phones based on engagement. Based on app metrics, iPhone users are more likely to use their device. That is why iOS mail in particular has the market share.
> Your immediate and slightly extended circle doesn’t equate to the entire planet.
Doesn't mean he wasn't right.
iOS is majority in a handful of countries, mostly small very rich countries (Monaco, Norway, Denmark), North America and Japan (probably Australia too by a smallmargin) and North Korea.
In UK to situation is 53% Android, 46% iOS, which is kinda strange for UK, the country of London, the temple of global finance. Being majority in UK is like having 80% of the market in Germany.
> Based on app metrics, iPhone users are more likely to use their device.
that's some spurious correlation there!
of course app metrics say that, Android users can use a web app! They aren't trained to only use whatever Apple wants them to use.
A considerable portion of the UK population lives outside London, and a lot of areas aren't necessarily the wealthiest in the world - meanwhile, with companies like Samsung and Google providing decent mid-range devices at much more affordable prices than most of Apple's lineup, they tend to do pretty well here.
I will, however, point out that from the statistics I've seen Apple has roughly half of the market share, with Samsung at about 30% - a pretty decent lead.
Doesn't mean he was either. It's well known that Android has the global market share. The point I made was that iOS is more popular with businesses, which explains why the iOS mail client see higher use than any other platform.
> Being majority in UK is like having 80% of the market in Germany.
Germany has a higher population by 16M people, just under twice the population of London. The average gross salary is $52K (€47K) in Germany vs $32K in the UK ($40K or £32K in London). German GDP is considerably higher too. So no.
> of course app metrics say that, Android users can use a web app!
But, outside of tech circles, do they? Anecdotally, I know a few android users and they tend to use exactly 4 apps regularly; Chrome, Insta, Facebook and WhatsApp. Even the technologists don't bother with web apps. So based on that and the OP's attestation, no-one uses web apps.
As of January 2023, the percentage of mobile users who use iOS-based mobile devices is higher in North Korea than in any other country in the world.
This trend is somewhat surprising, as iPhones are not legally available in North Korea. However, iPhones are considered much more secure than the phones which are legally available in the country, which consumers believe are often monitored by the totalitarian government of North Korean dictator Kim Jong-un. In light of this concern, a robust underground market for iPhones has emerged.
Although I'd personally expect Samsung to be huge there as it's their home market.
I have to agree overall though. Here in Spain most people use Android and midrange ones at that. If you see an iphone it's usually ancient or an SE or simply in the hands of a tourist.
For a normal Spanish wage an iphone is just too expensive. And the SE with its 7 year old design just not interesting enough for the huge price they still cost here.
> In the US for young people, iPhones make up 87% currently.
but the global US market is 55/45 not really a huge difference
> The global average is mostly dictated by whatever India and China use
Not really. It also depends on market penetration, in the west is around >90%, In China is below 50%, in India ~60%.
OTOH the fact that billion people can effectively communicate using cheap Android phones, means that expensive iPhones are not actually a necessity, but a luxury, we could get rid of them and still be able to do what we already do everyday. I
To me, the interesting bit here is that Outlook is still using the Microsoft Word layout engine.
That's what's going away: Outlook on Windows moves to the Chromium-lineage MS Edge web layout.
I idly wonder about legacy DIME (binary multipart MIME encoding from 20th Century Office products), but it's easier to run entire legacy systems inside a web render these days.
One of the Word layout engines really boosted Microsoft's dynamic web browser implementation in the early days; they had this compact, fast thing they could use already. IE 4.0 era.
This reminds me it was only five months ago a client sent a bug report about our software's e-mail notifications having broken layout. Turns out they were still using Outlook 2010, which only implements HTML 2.1 or some ancient standard that wasn't even HTML 4.01. We also learned that styling only applies to <table> elements, not <div> elements. So we re-wrote all <div>s to <table>s, but layout was still subtly broken. Eventually we decided it wasn't worth the hassle to consider an increasingly niche e-mail client that couldn't even bother to implement an HTML specification from 1999.
It’s not just Outlook 2010 that uses MSO, which is a buggy and incomplete implementation of HTML 3.2; the current stable versions of Outlook (for Windows) and Windows Mail do. This might be changing in the new version supposed to be released this year, not certain. MSO has had approximately two changes in the last 25 years (one to support high-DPI displays, can’t remember the other I know of).
> Eventually we decided it wasn't worth the hassle to consider an increasingly niche e-mail client that couldn't even bother to implement an HTML specification from 1999.
Glad you came around. This is probably the correct decision.
Markdown would be a pretty good fit as a compromise between HTML and plaintext for email. I wonder why no one has thought about that yet.
Markdown syntax takes a bit of time to learn, but with images, tables, limited HTML tags, I think it would suffice for 99% of use cases and remove the need for all the sanitization that current clients do.
Markdown is an authoring format. It’s OK as that. But it’s completely unsuitable as a publishing format, because there’s way too much variation of interpretation. Remember also that Markdown is built on top of HTML, more or less—you’d have to either ban all HTML tags (… which rather makes it not Markdown), or have just the same problems as before, but now worse.
People have suggested Markdown for email quite a few times. It’s a total non-starter, absolutely no chance of anyone doing it in the next few years at least (and I strongly doubt Markdown in any form will ever make it in like that).
Mail clients would need to learn to handle the markdown MIME type, and realize it could be plain text, or run through a converter to show as rich text.
But sadly too many folks use mail clients that render and compose HTML, or worse, and there would be no real incentive to switch. It might be a function of the sending client to send the prerendered HTML along with the plain text markdown part.
What if I need to share tabular data? An annotated image with discussion straight after it? Equations? People will have you make everything an attachment but that is much worse in terms of context switching. Absorbing new information is easier when the image is inline with text. Especially after it's been forwarded three times. We NEED formatted email, whether in the guise of a word document or HTML.
But I agree with you on context and having data visible right there in the email. It's often the case that people forgo using email as the functional communication technology it is and settles with attachments only and the canned byline.
I want to see full markdown, mermaid and the like in email.
It’s great outlook is finally ditching the 90s MS Word html rendering engine, but of course most big orgs do not update to the latest version for years.
So we’re still many years away from being able to finally dump tables.
And there’s still Gmail, which is also a giant pain-in-the-arse with basic things like media queries.
Then of course there’s the real question, what the hell is the point anyways? 82% of emails are primarily opened on mobile now (and a huge chunk on dark mode). Yet, hilariously, you go to sites like reallygoodemails.com and you see mini-desktop websites that mostly nobody will ever see in that format.
Why waste developer hours building mini-websites for a medium that is fundamentally ephemeral?
With the Office365 improvements (in particular to Excel) in recent years I would have assumed that many orgs are on the update channels for Office rather than doing manual rollouts.
I've had bosses that required their mail system (supported by me) to retain essentially all of their inbound and outbound email indefinitely. Many mobile devices seem to have merged email and messaging; messaging may be ephemeral, but email isn't the same as messaging.
Most of these "problems" with email seem to arise from problems with the big online mail "clients", like gmail. I didn't notice Thunderbird in their list of email clients (I use Thunderbird).
I deplore HTML-formatted email anyway. The last time I had to generate HTML-formatted email, the main problem MUA was Microsoft Outlook; I didn't realize that the problem was that Outlook used Microsoft Word's HTML renderer (TIL). I've always hated HTML-formatted email anyway, so jumping through the various hoops to generate HTML email automatically was a real drag.
The article's focus on the wonders of AMP as a solution is scary. AMP is a Google-controlled technology, widely-despised. Making AMP the solution to HTML email looks like a way of tightening Goo's already-tight grip on email's throat.
[Edit] So now a properly-constructed HTML email becomes a multipart with a minimum of three parts: text/plain, HTML and AMP. I don't see this as a wonderful new world.
I've made/remade the HTML emails for the B2B company where I work, so I read this with an eye for practicality.
The big all-important thing is that the Microsoft Word styling is out. It hurts in _so_ many ways when making a mail to be sent via Mailchimp/Mandrill.
Tables is just the example which is easy to convey, something everybody understands. Explaining why a margin/padding/whatever working slightly differently in Microsoft Word (AKA Outlook) and gmail can ruin a few of your days is more difficult.
Making an email that retains the styling in both gmail and outlook, even when the customer replies to it, can be a major endeavor. It sounds like that is changing.
Thank God.
I never thought about the fact that we’re emailing what are almost full webpages to each other. Or, well, to be precise, companies are emailing webpages to us.
The last two places I worked at that had office 365, everyone just used the web interface. It was pretty miserable but beat having a separate application just for email.
I've used auto tab discard for a long time and exempted the outlook tabs. I think Firefox was taking that feature to main, but not sure how they interact.
I don't go low on ram often enough to notice anything, or the exemption still works.
That works on Windows where alt+tab cycles between ... er, windows, but not on macOS, where CMD+tab cycles between apps. As another commenter said, the 'shortcut' feature (e.g. for PWAs) is a workaround.
Fun fact: Hacker News itself is structured predominantly with tables. Every comment/thread creates a new table nested within the context of its parent's table. It's tables all the way down.
Tables does not render reliably across platforms. This is because the algorithm for sizing columns and cells was never standardized.
Back when tables were the only tool available for layout, professionals combined tables with 1x1 pixel transparent gifs which could be scaled to force cells to have a fixed size.
I guess you could argue that tables combined with spacer-gifs are reliable. But solution exists which are just as reliable, much easier to use, and better for accessibility.
> It is hard to track down where a style is coming from.
This is an orthogonal concern. If you don't like CSS inheritance and cascade, you can just use style attributes directly on elements. I believe Tailwind uses a similar approach through class attributes.
> The new Outlook switches rendering engines from Microsoft Word to Edge.
This doesn't change the fact that only a portion of Outlook users use the new version, so the "no longer needed" statement in the headline is a bit exaggerated.
Really confused. Article is dated "April 2, 2023" and linked Microsoft blog is dated "SEP 28, 2022" and talks about a preview for New Outlook going live, but the article says "It's finally here"?
I always use plain text emails, but I won't debate it here, and I understand why HTML email exist.
But I want to point japanese plain text marketing emails. Those are marvels of unicode asciiart blocks, separators/lines and arrows. They even send HTML emails as text sometime, and the only HTML styling is selecting a font.
Tables? I’ll be glad when I no longer need to use weird embedded VML just to get background images or rounded corners! The Word HTML renderer was such a weird choice and such a step backwards when it was chosen. I think this article jumps the gun a bit but once the usage of versions of outlook using that fall enough for me to ignore it I’ll be very happy.
AMP seems a weird thing to talk about as something that helps. Even if you support AMP you still need to make the regular HTML content work so it’s just extra work to create, maintain and test. Why bother?
On iOS, Apple Mail supports 92% of the tested HTML/CSS features, while Gmail supports only 36%. What browser engine does Gmail use to have such poor results? Isn’t it all WebKit on iOS?
I used MH in the mid-90s. I was inspired by cks@cs.utoronto.ca. I worked at a regional ISP, and my boss used PINE (which was like Nano for email) and the power users used Elm (which was a popular MUA before it was known as a language). Yet, I used MH.
I decided on MH because I had a habit of subscribing to mailing lists, or at least being enrolled on them, without caring too much whether I read the messages. So I wanted a sort of NNTP-newsfeed-like way of splitting up all the mail into folders so that I could get work done while ignoring whatever was on those lists.
I believe I used procmail, piping everything that came in through ridiculous regexps and having MH sort them into mail folders, as it was wont to do. It was lovely, and I seem to recall always having a zero-size mail spool because even the unread stuff was going into a folder for later checking. I didn't use BIFF. Remember biff, not the VIC-20 user, but the mail notifier. I didn't need a mail notifier, because I always had mail. It was just neverending. MH helped me come to terms with that.
My highly customized MH environment was lost to the four winds when I left that regional ISP, and since I had no equivalent shell-based multi-user networked system in 1994, I didn't recreate MH and it fell by the wayside, for me, but probably not for Chris Siebenmann.
Despite some pushback, I worked on something similar (internally) for a previous company.
Having React/JSX for email templating (even if it was on top of MJML) is a great win for productivity.
All our front-end devs knew React, a couple knew Jinja, Pug or mustache. And every-time a team needed to add a new email template, their frontend devs needed to learn those again.
Instead they could just write email templates as they would write their regular components the way they do every day.
Uhh I am saving this one! Thanks! I remember the last time I had to set up a few mail templates it was so incredibly painful. Especially the testing of it is so painstakingly slow.
Just because there's some marginal benefit to AMP for Email, it doesn't make it good.