91–100 of 206 posts
I currently rely on https://emailclientmarketshare.com/ (by Litmus) for this but if someone's aware of a better data source, I'd like to know.
It would be really nice to have a small and simple markup language, say some markdown standard, to be the layouting language for E-Mails. No (external) images, just links, lists, headings, basic formatting. HTML E-Mails are a security nightmare, even if "only" CSS is "allowed" and JS/iframes/external images are not loaded.
Markdown is nice for composing, but not as a standard to be supported by many clients. CommonMark is an improvement, but there is way to many ambiguities and differences in supported features over different markdown parsers for it to be feasibly used as a standard. Markdown is also not any better than HTML in terms of security - most markdown parsers allow passing through arbitrary HTML, and then depend on sanitizing…
- You are correct that implementing markdown consistently is hard because there is no real spec. CommonMark is a spec, which helps, but a heroically thorough spec, so it's still not exactly trivial to implement.
- You are correct that markdown can escape to HTML. Indeed certain marketing email "features" probably would do this?
If I am missing something maybe someone could make an actual contribution to the discussion and explain.
In any case I think by far the most important point was made elsewhere: Google AMP is awful for the web and for email, both.
p.s. edit: Actually, I think the even more important point is that anything except plain text email is awful. :) So there, sure, use markdown or org-mode formatting conventions. Humans are pretty good at handling messy human protocols.
Earlier quoted context omitted.
I think that would be difficult to calculate accurately. We can collect user-agent statistics from browsers but mail clients don't have an equivalent when reading mail.
A number of email clients will add a header line that identifies them to every email that's sent.
The only people who can really use the headers to identify which email clients are in use are people who maintain very large ISPs. Although, even then, keeping track of the results of the IMAP ID command are probably more useful.
Isn't it time for desktop clients to embed a real rendering engine? The isolation on them has reached a good level.
Christ on a bike, the state of Outlook on Windows is absolutely miserable. I knew it by experience when I started preparing HTML signatures for our company, but seeing the list makes me even sadder about the absolute state of incompetency caused by legacy systems in Microsoft. For those uninformed, Outlook on Windows effectively works on a terrible (and terribly old) implementation of HTML that was initially develope…
Everything that discourages designers from doing fancy things is good in my book.
Earlier quoted context omitted.
Everything that discourages designers from doing fancy things is good in my book.
You don't get it. Stuff like this does not discourage designers. It is what gets them jobs and keeps them employed. I've worked with marketing departments where it was a designer's primary job to make things look good on email campaigns.
This is very cool. One feature I'd like is the market share report that caniuse has for each listing. I currently rely on https://emailclientmarketshare.com/ (by Litmus) for this but if someone's aware of a better data source, I'd like to know.
But email? The usual way statistics are collected are by embedding 1×1 tracking pixels in email messages and noting who requests those images. But that will undercount any email client that has the option to refuse to load remote images, especially any one that turns that option on by default (such as Thunderbird). Another way is to look at the headers of large corpora of email, but the only ones that are publicly available are going to be mailing list archives, which will tend to have a more skewed distribution.
Earlier quoted context omitted.
No markdown, but we had success with this one: https://mjml.io/ Try out the online examples.
Wow, that's pretty cool, what's the consistency across different clients like? Having email rendered consistently across many email clients was the main reason we stayed with Mail Chimp for so long...
The actual markup MJML generates is terrifying, and can be very large payloads. A simple hero graphic, some styled body text, a few buttons, and a footer was around 60KB/message. It got gnarly for us as our MTA had a max-payload size per API 'send' call (Mandrill) so our max send rates were partially constrained by MJML's fat markup.
But totally worth it to not spend _as_ much time satisfying the mail clients of the world.
Actually, I'd prefer if they added something like CommonMark and removed HTML.
Isn't it time for desktop clients to embed a real rendering engine? The isolation on them has reached a good level.
Every GUI desktop client I'm aware of embeds a real rendering engine. The difficult one is Outlook, because Microsoft made a conscious decision that compatibility between Outlook and Word was more important than between Outlook and web browsers. I believe the Word/Outlook HTML engine was based on IE 5.5.