(My opinion as another one who has been slowly working on my own browser engine.)

The least-needed features are often accessibility nightmares (e.g. animation - although usually not semantic).

The accessible subset could then be government standardized and used as a legal hammer against over-complex HTML sites.

For a while search engines helped because they encouraged sites to focus on being more informative (html DOCUMENTS).

I think web applications are a huge improvement over Windows applications, however dynamic HTML is a nightmare. Old school forms were usable.

(edited to improve) Disclosure: wrote a js framework and SPA mid 00's (so I've been more on the problem side than the solution side).

   <meta name="dependencies" content="mathjax/1.1 highlightjs/2.0 navbar/5.1"/>

I just want one of these browsers to give me a proper ComboBox (text, search and drop-down thing)

But now we have best of both worlds: use <table> for the actual tables, and CSS grid for UI layouts.

care to tell us more?

("I don't need to worry about the second axis" seems to be a "not thinking fourth dimensionally enough" excuse to me today. You haven't considered enough responsive breakpoints or you haven't considered future features or future expanded data or future localizations, yet.)

Well, until everybody just gave up and declared it a "Living Standard".

I think we do still need something like this, but I worry that basing it on versions of the spec is just repeating the same DOM levels mistake.

Could such a standard be based on the subset of HTML/CSS acceptable in emails? Maybe with a few extra things for interactivity.

(While on it, can we also ban loading images from third-party servers?)

But I don’t see any email clients with somewhat significant market share going through with this :(

If it actually gets mainstream adoption or goes into the standards pile it another question entirely.

Your standard still needs to render in Outlook on Windows, though, which means you need to support the weird Office version of IE11 as an upper limit.

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.

I think something like a reference implementation (Ladybird, Servo or even Vaev maybe?) getting picked up as the small-web living standard feels like the best bet for me since that still lets browser projects get the big-time funding for making the big-web work in their browser too. "It's got to look good in Ladybird/Vaev/etc".

An idea: a web authoring tool built around libweb from Ladybird! (Or any other new web implementation that's easily embeddable) The implied standard-ness of whatever goes in that slot would just come for free. (Given enough people are using it!)

The phrase "living standard" is an oxymoron, invented by the incumbents who want to pretend they're supporting standards while weaponising constant change to keep themselves incumbent.

A "standard" should mean there is a clear goal to work towards to for authors and browser vendors. For example, if a browser implements CSS 2.1 (the last sanely defined CSS version), its vendor can say "we support CSS 2.1", authors who care enough can check their CSS using a validator, and users can report if a CSS 2.1 feature is implemented incorrectly.

With a living standard (e.g. HTML5), all you get is a closed circle of implementations which must add a feature before it is specified. Restricting the number of implementations to one and omitting the descriptive prose sounds even worse than the status quo.