Pick a subset aimed directly at accessibility.

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

Styles can be provided as client-side dependencies instead of free form CSS:

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

then browser decides how to resolve them.

That's easy to specify but contains a lot of bloat and unused features. A slimmer but more modern set would be useful.

I feel like some of the newer standards like CSS Grid instead of tables might be the best way to go. Many HTML/CSS improvements were not just bloat but actually better standards to build on.

Right! Crazy fonts or cursors, not on smolweb (as another use put it) but Flex and Grid are almost necessary. There are loads of things that could be dropped (it feels like).

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

You still need to have tables.

And <marquee>, of course.

But the rendering engine might be easier to build with TABLE as a specialization of CSS Grid layout rendering rather than the slow real world work of CSS Grid being a generalization of TABLE rendering.

From accessibility background: Please stop using CSS for table data. It does not translate to my screenreader.

Yes, but grids are everywhere in the UIs, not just the tables. In 2000-s, the problem was the opposite of what we have now: every interface was a table full of tables, because there was no other way to position things reliably.

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

But older versions contain lots of crap we don't need (eg <blink> tags) and miss out on useful stuff (grid layout).

> slowly working on my own browser engine

care to tell us more?

Cat is out of the bag. nobody wants their CSS without flexbox anymore. It has to include that.

Everything flexbox can do, CSS Grid can do, with easier/better/cleaner support for the second axis. At this point, I'd be interested in dropping flexbox entirely for CSS Grid.

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

Why not start with what is required for markdown formatting? Then build out from there.

Sounds kinda like DOM levels: https://en.wikipedia.org/wiki/Document_Object_Model#Standard...

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.

Sites often get that wrong. I'd say support motherfuckingwebsite.com subset: <p>, <a>, <h*>, <img>, <ruby> (i.e. markdown/gemini++) and do everything else with webcompat/fixbrowser way.