What an excellent resource! (And yes Outlook is a pain and supports so very little!)<p>We've tried building email templates for notifications for our apps where I work, and it has typically been a pain. We have since swapped to using mjml (<a href="https://mjml.io/" rel="nofollow">https://mjml.io/</a>) to build the templates, and it's working wonders. The output seems the be the most compatible with all different devices that we've tested on.<p>The other tool we enjoy using is Litmus (<a href="https://litmus.com" rel="nofollow">https://litmus.com</a>), which allows you to throw in an email template and see what it looks like on all kinds of apps and devices. Other thread here mentions <a href="https://testi.at/" rel="nofollow">https://testi.at/</a> as well, which we've also had success with.<p>All of these have been really invaluable to designing emails for our apps.
Hilarious anecdote about this website: the owner once said there are tons of entries in the usage log of people misunderstanding the purpose of the website and inputting celebrities names to try to email them. :D
The lower the score, the better. I know many who have a policy of "emails must be in plaintext only, with no attachments unless agreed to in advance; everything else gets deleted automatically."
A fully-featured HTML "document" is really an application, not a document at all, so it makes sense that mail clients limit support. But this fragmentation makes me yearn for a real standard here, an official non-application subset of HTML that doesn't allow fetching remote resources or executing code. Just a document format with embedded media, animations, styling, etc.
FWIW jsx-email has a builtin CLI email client compatibility check which uses the caniemail dataset: <a href="https://jsx.email/docs/core/cli#check" rel="nofollow">https://jsx.email/docs/core/cli#check</a>
I think it would be more useful to list the few CSS properties that all email clients do recognize. I don't mean to be flippant. I'm serious.<p>CanIEmail? The answer is generally no.
Dark mode support in email is one of the most frustrating things I’ve dealt with as a frontend dev who’s been coding since the IE6 days.<p>Basically you have to accept that you must only implement a light mode design and choose colors that will look okay when automatically inverted by all of the shoddy dark mode email client implementations.<p>Gmail is one of the worst offenders. You have zero recourse for picking your own colors for dark mode.
Isn't AMP considered an antifeature these days? Last I heard even Google had abandoned it — but this is outside my zone of expertise, so I might be wrong?
I can't figure out how to use it.<p>When I enter "<a href="<a href="https://example.org>Test</a>" rel="nofollow">https://example.org>Test</a></a>" it says "No results found. Why not suggest this feature to be added?".<p>When I enter "<a>" I get "AMP for email", "BIMI", "accent-color" and lots of other CSS attributes starting with "a" as result.<p>When I enter "a" I get the same as above.<p>How do I check if I can email the HTML Anchor tag? The input says "HTML, CSS, ..." but it doesn't seem to understand HTML unless I'm doing it wrong?
Hehe, apple mail supports marquee very recently... Outlook even more so! 2020!<p><a href="https://www.caniemail.com/search/?s=marquee" rel="nofollow">https://www.caniemail.com/search/?s=marquee</a>
I use plain text, and I even enable "block external image" on the client, and I would advise others to do the same, because there is just too much phishing with email..
I like plaintext better (<a href="https://useplaintext.email/" rel="nofollow">https://useplaintext.email/</a>).<p>And emails can totally be sent both as plaintext and HTML, so that the receiver can choose! I just don't understand why so many services only send a text/html version instead of both text/html and text/plain.
So, does Android support inserting images yet into HTML email you compose with an app, for the user to send?<p>It's been A DECADE NOW<p><a href="https://stackoverflow.com/questions/15136480/how-to-send-html-content-with-image-through-android-default-email-client" rel="nofollow">https://stackoverflow.com/questions/15136480/how-to-send-htm...</a>
MJML is better than most but remember every templating language has a footprint.<p>When possible reduce your html code weight to the bare bones minimum. Nothing too fancy. Keep it logical. After a bit of practice it’s actually easy and in my opinion often faster than MJML (For example MailJet. Don’t even get me started on Klaviyo.)<p>Even with minimal coding/hmtl experience you can run your code through GPT-4/Bard.<p>Bonus for including custom instructions such as “transactional intent”, Bayesian/heuristic filtering, coded for users with poor digital accessibility, under-served internet users, etc.<p>Even with the best domain domain/ip reputation without a positive engagement history specific to that user you will often land in promotions/other tab and not the primary tab for new users with a heavily weighted creative.<p>Remember you want to mimic “an email from Grandma” while maintaining some degree of control of visual design.<p>Or if that’s too complicated just keep your subject line under three words and all lowercase.
Flashbacks to making a nice email template for a company only to find out their entire client list used outlook from a decade earlier and could just about render plaintext. There was no point in me even showing up.
Is there something like this for features techies might care about? Like some sort of guarantee of at-rest encryption, SMTP/IMAP/POP/etc support, end user encryption, reasonably fast search<i>, backup/restore, etc.<p></i> GNOME Evolution and Thunderbird, at least last I used it, have abysmal search speed, taking seconds to search through a <i>local</i> DB of a few thousand emails. So they're clearly using search tech much inferior to a local DB with indexes.
> Apple Mail (iOS) : 266/284<p>> Gmail (Android) : 111/284<p>Interesting corrective to the “Apple is holding back HTML” narrative that appears so often on HN.
I would love for a middle-ground to emerge - plain-text emails with rudimentary formatting and ability to inline images. Something like markdown/asciidoc would be fine for overwhelming majority of cases. Unfortunately we ended up in a world where HTML email is a commonplace…
Outlook supporting padding in 2003 then not really supporting it in any follow up client sounds just about right for the dumpster fire experience that is trying to make an email look nice.
I wish there was something like BrowserStack but you send a test email and it shows you how it renders on tons of different email clients on various platforms. It wouldn't work for web-based email like Gmail but it would still be useful.
Soooooo happy that my mail client is not even on the list here. It automatically strips out anything remotely looking like html and it sends out plain text emails only, as email was designed to be and should still be.<p>Anyone sending me css garbage will be directed to /dev/null. Thanks.