"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.