A lot of issues with this post, but I'll just take two:
> rather than articulating particular requirements and principles but not how they need be met, the WHATWG specifications tend to be written in a highly algorithmic and prescriptive style; they read like a web browser's source, if web browsers were written in natural language.
It turns out that if you want to have pages work the same in every browser you need to have every browser doing the same thing when it interprets the pages.
> The pursuit of the semantic web has changed in the era of HTML5, which represented a rejection of XHTML — to me, a seemingly bizarre rejection of having to write well-formed XML as somehow being unreasonably burdensome.
In practice, people won't write valid XML. We had a lot of cargo-culting, people putting self-closing tags into HTML, but people weren't using XML editors. And without an editor that understands XML it definitely is unreasonably burdensome to create XML. What we saw instead was that even most "XHTML" documents were not valid XHTML and were served with an HTML content type. If you had served them instead with an XHTML content type the browser would have simply refused to render them.
Both of these were recognitions that the previous approach wasn't working, and that if the spec was to achieve its goals we needed to try something different. Under WHATWG the spec has moved from "yes, the spec says this but it doesn't matter" to "the spec describes what the browsers do, and the browsers treat cases where they violate the spec as bugs". Sites now really do work the same across browsers, and WHATWG deserves a lot of credit for that.
> In practice, people won't write valid XML. We had a lot of cargo-culting, people putting self-closing tags into HTML, but people weren't using XML editors.
That's probably the most popular argument against X(HT)ML and in favour of HTML5. In fact I think among the popular programming/markup languages, only very few are so forgiving. Namely it is HTML(5), JS, CSS and perhaps Shell script and Perl. But even in these cases following best-practices and using Linters has become extremely popular. On the other hand you have strongly typed languages or even languages like Python or Makefiles that even make sure you use consistent whitespaces.
I think nearly everybody uses quite powerful editors with a load of plugins these days because accelerate editing and also do autoformatting.
> Sites now really do work the same across browsers, and WHATWG deserves a lot of credit for that.
On the other hand there are just 2 popular/"usable" browser engines left. I think XHTML is far more modular, maybe it would even be possible to outsource some browser rendering tasks to XSLT transformations. HTML at one point became a messy standard through the Browser competition and then WHATHG somehow manifested that situation I guess. Now there's a massive monoculture of Browser engines.
This is one of the things I liked so much about XML; you could have a single document and use XSLT to generate a web page or (via XSL-FO) a nicely-formatted print document.
The way developers test Blink/Webkit still (they just test one browser in the family, be it Chrome or Safari largely depending on the web developer's home hardware) it's hard to consider it a hard enough fork to count as two separate engines. Sure, reality shows more divergence than such web developers that test that way tend to generally expect/believe (Safari as Apple-only "LTS" Chrome), but that perception and its reflection in testing alone seems reason to consider the family together (especially with Edge moving into the "family" for among other reasons that very reason of "simplifying web developer testing requirements").
> it definitely is unreasonably burdensome to create XML
Disagree. You open the tag, you close it. Nested. I worked with a non-developer who had some KML (https://developers.google.com/kml/) dumped on her without any training whatsoever and when I explained a few basic thing, including the above rule, she got the principle of it in a few minutes. Because it's not hard (although dumping a KML task on a non-dev is a bastard thing to do).
> but people weren't using XML editors
I personally think that lowering the bar to let as many people in as possible isn't necessarily a good idea. Just IMO
I wonder how many people think it was unreasonable due to how you had to send back the page to be truly valid; application/xhtml+xml, application/xml, or text/xml. Due to IIS, browser support, and the platforms I personally used, that was the only requirement I never felt I had to meet.
I personally agree with you, and still close my tags, use quotes around attribute values, and provide empty/duplicate values when needed.
I also still use XML for data storage, and used ColdFusion back in the 6/7 days, so that probably had a influence on my choices.
I agree the approach sounds reasonable, and I think if we were having this conversation twenty years ago I would have been on the pro-XHTML side. But we tried it, and it didn't work.
XHTML could either be served as HTML or as XML. When served as XML it would not render in all browsers, but when served as HTML it would. Since serving as XML did not provide any particular value for the document author, there was no reason to use it. But XHTML served as HTML is just HTML with some extra slashes which are ignored.
> It turns out that if you want to have pages work the same in every browser you need to have every browser doing the same thing when it interprets the pages
Yes, but the change was that first browsers adapted to the standard, now the standard adapts to the browsers. That's the big change.
And this makes it better how? That's one of the reason a blink quasi-monopoly is not a good thing. We risk them becoming the standard to which the web must conform.
On the other hand, an independent standard organization (which, of course, the w3c isn't) would not have to follow a browser's vendor agenda. They'll ideally want to do what's right for the web.
To sum it up, I don't think having browser vendors set the standard is in the best interest of the web platform, especially when they are so unequally represented in actual usage (and we can debate about how we got ourselves in this situation).
Web development today is loads better than it was.
Then: if I wrote to the spec I would find the major browsers would all handle my page differently. Writing complex cross-browser pages was a constant pain involving IE-specific hacks (special CSS comments that only IE understood). The browsers were not interested in implementing the spec because it meant a ton of work for no benefit and existing pages would break, and the W3C had moved on to XHTML-only approaches.
Now: I can write to the spec and the major browsers (based on WebKit, Blink, EdgeHTML, and Gecko) will all do the same thing with my page. Spec violations are bugs, and are taken seriously by the browser vendors.
(Disclosure: I work for Google, though not on Chrome)
But what benefit is a standard if browsers does not implement it? It can be "right for the web" only in a theoretical sense if it is never implemented.
> rather than articulating particular requirements and principles but not how they need be met, the WHATWG specifications tend to be written in a highly algorithmic and prescriptive style; they read like a web browser's source, if web browsers were written in natural language.
It turns out that if you want to have pages work the same in every browser you need to have every browser doing the same thing when it interprets the pages.
> The pursuit of the semantic web has changed in the era of HTML5, which represented a rejection of XHTML — to me, a seemingly bizarre rejection of having to write well-formed XML as somehow being unreasonably burdensome.
In practice, people won't write valid XML. We had a lot of cargo-culting, people putting self-closing tags into HTML, but people weren't using XML editors. And without an editor that understands XML it definitely is unreasonably burdensome to create XML. What we saw instead was that even most "XHTML" documents were not valid XHTML and were served with an HTML content type. If you had served them instead with an XHTML content type the browser would have simply refused to render them.
Both of these were recognitions that the previous approach wasn't working, and that if the spec was to achieve its goals we needed to try something different. Under WHATWG the spec has moved from "yes, the spec says this but it doesn't matter" to "the spec describes what the browsers do, and the browsers treat cases where they violate the spec as bugs". Sites now really do work the same across browsers, and WHATWG deserves a lot of credit for that.