Hacker News new | ask | show | jobs
by integralid 310 days ago
>The whole story of

Is that really the story? I think it was more like "backward compatible solution soon about more pure, theoretically better solution"

There's enormous non-xhtml legacy than nobody wanted to port. And tooling back in the day didn't make it easy to write correct xhtml.

Also like it or not, HTML is still written by humans sometimes, and they don't like parser blowing up because of a minor problem. Especially since such problems are often detected late, and a page which displays slightly wrong is much better outcome than the page blowing up.
2 comments
throwaway346434 309 days ago
More or less? https://en.m.wikipedia.org/wiki/WHATWG is fairly neutral. As someone in userland at the time on the other side of it, it was all a bit nuts.

IE we got new standards invented out of thin air - https://developer.mozilla.org/en-US/docs/Web/HTML/Guides/Mic... - which ignored what hundreds had worked on before, which seemed to be driven by one person controlling the "standard" making it up as they went along.

Microformats and RDFa were the more widely adopted solutions at the time, had a lot of design and thought put into them, worked with HTML4 (but thrived if used with xhtml), etc etc.

JSON-LD/schema.org has now filled the niche and arguably it's a lot better for devs, but imagine how much better the "AI web UX" would be now if we'd just standardised earlier on one and stuck with it for those years?

This is the main area where I saw the behaviour on display, where I interacted most. So the original comment feels absolutely in line with my recollections.

I love bits of HTML5, but the way it congealed into reality isn't one of them.

link
lucideer 309 days ago
> There's enormous non-xhtml legacy than nobody wanted to port.

This is a fair argument if content types were being enforced but XML parsing was opt-in (for precisely this reason).

> And tooling back in the day didn't make it easy to write correct xhtml.

True. And instead of developing such tooling, we decided to boil the ocean to get to the point where tooling today doesn't make it any easier to lint / verify / validate your HTML. Mainly because writing such tooling to a non-strict target like HTML is a million times harder than to a target with strict syntax.

A nice ideal would've been IDEs & CI with strict XHTML parsers & clients with fallbacks (e.g. what Chromium eventually implemented)

link