Not a framework but I’ve found Ted Goas’ Cerberus templates very useful.

I customized them, extracted them into modules and created a design system which I then translated to an email CMS.

Coverage is pretty good although Outlook still glitches in some circumstances.

https://tedgoas.github.io/Cerberus/

FWIW caniemail is unreliable and does not have full coverage.

Also with this level of complexity I’d rather start with a few tested patterns than navigate the insane labyrinth of email client inconsistencies.

Yep, I think we need more tools like this around.

Why is MJML a non-option? It was a huge time saver for me. Combine it with react-mjml and you can get typesafe email templates that work in pretty much any browser. I managed templates by hand for a long time, and it took me a couple weeks to replace everything with MJML, but it was worth it.

I'm remaking my workplace's transactional emails these days (order confirmation, receipt etc. for an online shop - emails customers also reply to when stuff doesn't go as expected). We want something responsive for smartphones, but are primarily a B2B company.

I made what they wanted with MJML. Looked good in a browser, gmail and phone.

Outlook had a few issues, can't remember which right now.

But replying from Outlook simply broke the styling completely. Gaps between each section, complete mess. Not the impression you want to give the customers when their order goes wrong. B2B means Outlook is what out customers use.

I've found that replying via Outlook is the ultimate integrity test of an eamil.

Now I'm making them by hand and it is a madening cargo cult bonanza. Takes a lot of time.

I guess MJML is fine for marketing.

> But replying from Outlook simply broke the styling completely

This is an Outlook problem, not an MJML or even an HTML problem.

If you inspect the HTML for the email sent vs what Outlook sends on a reply you’ll see it has changed the code.

Here’s an excellent highlight of this bug https://www.hteumeuleu.com/2016/super-mail-forward-an-email-...

> This is an Outlook problem, not an MJML or even an HTML problem.

Though you are technically correct, I just don't think this is a constructive attitude. Half the job of making emails is working around (Outlook) bugs. This is just the annoying world email coding.

If MJML is content ignoring Outlook bugs, MJML just isn't a satisfying tool for email makers.

Sure, it'll get the job done for some marketing, but now the developer isn't learning skills that will make robust emails beyond that.

Making robust emails becomes a completely separate skillset and the developer who chose to invest time in MJML will have to start all over learninging the necessary skills if he needs to make email you can actually reply to.

> Though you are technically correct, I just don't think this is a constructive attitude.

I’ve worked in email for a decade, you do what you can with the tools you've been given. An email will never look perfect everywhere and while I agree with the general sentiment you’re talking about regarding folks learning proper email code rather than relying on tools, I also think the quality of emails sent is substantially higher now thanks to those tools.

The end user doesn't know that, and doesn't care.

Your boss is not your end user. The way your boss interacts with the emails you send is not the way your end users do. Optimising for your boss is not how this channel should work, though I appreciate there are a lot of bosses out there who don’t understand this.

I don't understand your point.

Are you complaining that his boss is forcing him to implement something that his end users can use?

If so, why isn't his boss right?

Personally, I'd say that yeah, he's supposed to work for his end user, why would he do anything else?

My point is that, from the perspective of email, you frequently receive internal feedback that doesn't correspond to how users actually use email.

For example, if the org uses desktop Outlook but < 1% of your audience does, is it worth optimising the email for that audience based on internal feedback?

If someone notices that something weird happens when an email is replied to or forwarded, is that something worth acting on based on the real world frequency of that action?

I agree, I’ve had pretty good results using MJML now for several years (and I’ve been doing HTML emails since almost the 90’s!)

This is a problem area where a good abstraction framework is highly useful in my opinion.

That said I don’t specialise in email, it’s something I do “when I need to”. So if I was spending more time doing this sort thing, I might be more inclined to move down an abstraction level back to HTML/CSS and improve my knowledge of various client support.

To just get the job done though, MJML is highly recommended.

I see also a lot of mentions on this thread about replying to emails breaking the layout. Part of me thinks we’re fighting a losing battle here anyway so there is a limit to how much time it’s worth spending to make sure even replies are formatted nicely across all clients. But the other thing to consider is whether the email template is just trying to do too much.

I try and keep my email templates very sparse, clean and simple and I generally haven’t had too many issues with reply/forward formatting (that I’m aware of).

What’s wrong with MJML?

I don’t want a framework to lie to me about what it is that I’m writing.

I’m not interested in learning MJML. I’m interested in learning what subset of HTML and CSS email clients render and rasterize to.

That’s it.

I’m sick of stupid developers shilling their software product that I’m suppose to build other products with.

They do it with these cutesy photoshop/illustrator logos and dribbble crafted color schemes and drop in things like made with love in (city) in their README.mds on GitHub.

I want tools, not someone’s amateur marketing campaign.

"I’m interested in learning what subset of HTML and CSS email clients render and rasterize to."

Doesn't sound like you want a framework. Sounds like you want a book.

Nope, plenty of CSS frameworks out there that don't try and make up their own tags.

The thing about email is that renderers aren't even implementing the same spec. There is no common subset to learn. Every client implements some vague mess of 1997-era HTML/CSS mixed with different random modern features. Any attempt to try to write anything slightly advanced manually will drive you insane. Mail clients will mangle your code in ways you can't imagine. Every client will mangle it slightly differently. Even the same client on different operating systems will behave differently.

Tools like MJML take a compiler approach to email. Why waste time trying to figure out how to implement a for loop in machine code and keep it updated every time a new processor comes out when you can just let the compiler do it?

Take the top email clients and you'll sure as hell find a common subset. I don't want something slightly advanced. Emails are text and images. That it's. There's nothing advanced about that, and I'm not looking for it, either.

The idea we need compilers for everything is idiot engineering.

If you just want text and images, you don't need CSS. Just the <img> tag - and even there you'll run into differences if you try and use the alt attribute.

And even that isn't trivial. For example, say you include an basic black on white icon, what happens if the user is using dark mode? If the image is transparent, it becomes entirely invisible. If it's non-transparent then it's ugly (white box). If you want to make it change depending on dark or light mode, now you have to use responsive CSS which works entirely differently in different mail clients. What happens if the image is bigger than their viewport? Hint: it is different in different clients.

And speaking of mail clients: one of the most popular mail clients is Outlook, which on Windows uses the Microsoft Word(!) HTML renderer and on Mac it uses WebKit. Gmail on web has its own HTML parser that outputs different HTML to what you wrote (and mangles your CSS class names). Apple Mail is probably the easiest to deal with.

It's not worth learning this stuff if you don't have to. It will not benefit your life in any way. The common subset you want is text/plain.

The very site this thread is about addresses exactly this. The tl;dr is look at what is supported by Outlook.

MJML is abstracted from Mailjet’s email builder. It’s based on real-world HTML needs and the stuff it renders is pretty easy to read. You’ll end up re-implementing something like it if you try to go simpler but have a lot of work to do.

It’s also easy to teach to designers.

>learning what subset of HTML and CSS email clients render

You can use Table and all its related fields, span, h_, and p. Anything else is risky.

For CSS you can set the font color and size. Setting a font itself is risky. Avoid using anything else including margins and padding as these largely don't work properly. multi layered tables are your margin and padding system. You also can only use inline styles. No classes, style tags or linked styles.

Thats about it for email. Have fun.

Great! Now document it, create a getting started template, some component snippets, and examples, and you basically have a project that I want in my toolkit.

Not being snarky here: Isn't that what MJML is? It has components and examples and does all the nasty nesting table hacks for you.

Asking because all I know of it is from their site. I have not used it myself. Does it have its own glitches that come along during the attempt to patch over other glitches?

No, it emphasizes itself over standards, and promotes compiling beyond the scope of inlining CSS. That's enough to turn me off. It's self serving. It's not serving my needs.

https://maizzle.com/ does that—of course, you'll then have to deal with using tables to layout content manually instead of using MJML's abstractions.

Mind you, I haven't used this in too long, but when I did I don't recall any issues.

https://get.foundation/emails/zurb-stack.html

There's a big problem with Foundation for Emails right now - the Saas workflow requires Node v10, which is now unsupported. You can't easily start a new project. It's unclear if this will ever get fixed.

I'd argue against frameworks and for providers to simply update the HTML and CSS they support. Its still bloody tables.

I think HTML emails are unnecessary. It's only useful for advertising, marketing and tracking. If you want to show fancy css and design, link a website. If email was used as what it was designed for, writing electronic letters to each other and not spam and ads and marketing, we wouldn't have any of these problems.

I can't agree. I quite like html email. I just wish that it had an extremely cutdown subset (just colors, a few "header" sizes, italic, bold, underlined links), NO CSS allowed, no specifying of fonts other than say mono or "other". Maybe inline images links so that attached images could insert. No tables. Only <li> or <ul> Such a system would still be completely readable as plain old text. Now everyone thinks they have to use the kitchen sink approach or that there's not a middle ground.

I 100% agree.

I would love something like very simplistic markup, doesn't even have to be HTML. Just something to inline some images and differentiate text.

Everything else is just horrible.

I get so many emails with basically websites in them, but when you click on a product, the deep link is broken and you just end up on the storefront.

I'd much prefer a small text that talks about the product and explains a few things and then a working link to that product.

You should take a look at https://heml.io/