HTML parser is trivial. There's a huge difference between HTML parser and HTML rendering engine. "A minimal browser" which you allegedly wrote isn't something you or anyone else does, or would, use.
I didn't "allegedly" write it, it's on my github.
Yeah it doesn't do box model layout but (and this was my point) that's not as big a deal without js because the pages are still perfectly usable.
I wrote a toy browser in a weekend too; I just used an existing HTML and CSS parser. The hard part isn't the HTML parsing, that's pretty easy and mostly just basic lexing/parsing stuff. It's applying the CSS to the HTML and rendering a document that vaguely looks right. There are loads of different interactions, and even Firefox and Chrome actually get it wrong in many edge cases (and also frequently in not-so-edge cases). I wrote a list some time ago of all the interactions "position: sticky" breaks in Firefox, and there's loads of them (I can't find that list now though, it was a HN comment from last year). It was pretty basic stuff like z-index, tables, flexbox, etc. Nothing too obscure.
If a lot of the cruft would be removed then actually, it probably wouldn't be so bad. But you know, compatibility and such. Still, a <link rel="newstylesheet" href="style.newcss"> probably wouldn't be such a bad idea. The base CSS specification can probably be reduced by half if not more, both by removing cruft and by learning from mistakes.
There are a great many pages that are not usable on a browser that does not implement JS. None of these things are "hypertext" anymore, the original idea was that all web locations would fall back to simple text rendering of the content, the fact that much of the modern web can't be read on a base HTML renderer is more of a statement of what a website is now - an application server.