AFAIK, "email HTML" isn't standardized either; most organizations that make nice-looking HTML emails have to do a ton of testing across different clients and come up with workarounds to make everything look consistent.
It's fascinating how much "email HTML" is trapped in about HTML ~2.5, with limited CSS support and still a ton of FONT tags and TABLE layouts.
HTML 2 might be an interesting subset of HTML to "focus on" for smolweb, but it would be a big retro throwback, and not feel at all modern.
If you were starting today, might be more interesting to start with the most modern stuff and work backwards. HTML 2 TABLE could be implemented as a specialization of CSS Grid, for instance.
Google has recently been pivoting AMP which nearly broke the web towards email. It might actually be a better use of AMP than the web, but I'm still skeptical about some of its privacy stance and ad-injection focus: https://amp.dev/about/email
Does the email client on Windows still use IE11? (Some older versions might still have significant market share, but I’m not sure it would be for much longer?)
"Outlook (New)" (aka "One Outlook") is React Native with a full Chromium webview, and the transition from out-of-the-box Windows-provided "Outlook Mobile" (Windows 8-10) to "Outlook (New)" has mostly completed, but the transition from Outlook (Classic) (aka "Bloated Corporate Outlook") seems somewhat stalled because a few big corporations have extensive plugins and cranky IT admins. (Also Outlook Mobile had a better than IE11 support and also has been Chromium on most platforms, it is "Outlook (Classic)" that continues to haunt us all with its ancient Word-based micro-browser fork of IE.)
No interactivity! The email must be printable as-is. Not even CSS code to change styles when you hover over links. That's what I would for a minimum HTML for emails standard that's widely supported.
It’s actually a bummer: you can’t use a <style> tag because some email clients don’t like them. Instead, you have to inline your styles in every element. the lack of :hover is just a side effect of that I think (although it plays out nicely here).
(While on it, can we also ban loading images from third-party servers?)
Hmm, that might not be a bad idea! We could ban CSS altogether: just leave some markup tags, maybe whatever you can do in Markdown + tables. No colors, no small print, no images. (We could even use something like gemtext as the format instead of HTML, but that wouldn’t be backward compatible with clients.)
But I don’t see any email clients with somewhat significant market share going through with this :(
I'm confused, we're talking about browsers, and comment I replied to suggested 'email + interactivity' as a standard for minimal browsers. I wasn't suggesting adding JS execution to emails. (I don't even allow remote images personally.)
Could such a standard be based on the subset of HTML/CSS acceptable in emails? Maybe with a few extra things for interactivity.