HTML 5.2 is done, HTML 5.3 is coming

But in practice that isn't a good example. Given HTML's extreme error tolerance the practical difference is zero. It only makes a difference for authors, who really should consider it an error to use more than one <main> tag.

I don’t read the rest of W3C’s spec to be honest. It’s useful to have a brief summary of changes to see where things are heading (and any convenient changelog implies some kind of versioning), but I’d likely be checking MDN or WHATWG for specifics if something catches my eye.

For example, after I saw the new <dialog> tag in W3C’s changelog, I jumped to MDN to find a friendly overview of its usage and a compatibility table (spoiler, the tag isn’t supported by most major browsers).

But w3c on this link says:

„Multiple main elements in the DOM, so long as only one is visible to the user.” - so they allow multiple main elements as long as single one is visible, right?

I've created a SGML DTD grammar for W3C HTML 5.1 validation at [1], and am in the process of adding 5.2. This is of course only for checking and normalizing HTML the markup language, rather than a reference for Web APIs and browser behaviors.

[1]: http://sgmljs.net/docs/w3c-html51-dtd.html

Those are both 3rd party offerings and could disappear at the drop of a hat. It's not a good practice for a standards body to rely on outside parties to write documentation for their work.

"About the only browser fully supporting XHTML was Firefox and authors hated it because the spec also demanded a yellow page of death if the XHTML had any syntax errors."

And this, kids, is why the Internet is, and always will be, such a mess. That was, and always will be, the correct approach to pages with syntax errors. Everywhere else trying to silently 'fix' syntax errors was soundly rejected as a source of innumerable bugs, but on WWW they are treated like line noise.

Why blame the W3C for developing XHTML 2 instead of blaming the browsers for not implementing it?

XHTML 2 was the way to the Semantic Web. The point was to get rid of JavaScript, extend HTML and CSS and eventually replace them by XSLT and semantic open machine-readable (XML) data formats. The outcome would have been for web browsers to become mere document readers and everything else to be done with native applications able to read and work with interoperable formats. This would have given authors less control, browsers less power (and market share, if web pages did break), and advertisers less revenue.

HTML5 was the way to the web as a virtual machine for web applications, which gave authors increased control, advertisers full reign over users' web browsers, and an ever more complicated and resource-hungry web platform[1] tolerant of any web page however bad its code.

In hindsight the theoretical purity would have had real benefits for real users.

From the HTML Design Principles:[2]

> In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for multiple constituencies at once.

Theoretical purity is listed at the end as if theoretical purity had nothing to do with the users' interests. The wording makes it seem as if users cared about nothing but "costs or difficulties" (think about the poor users who will have "difficulties" if web pages break!).

Nowadays the W3C (EME) and WHATWG are both enmeshed in commercial interests and the organizations left that publish web and document standards are OASIS (which publishes the OpenDocument and DocBook standards) and the IETF.

[1]: https://platform.html5.org/

[2]: https://www.w3.org/TR/html-design-principles/#priority-of-co...

WHATWG is now led by a Steering Group of the four major browser engine vendors, and for some time has had a rule that every new feature in HTML needs a test suite and implementation commitments from multiple vendors before it can go in. It’s definitely not right to claim it’s controlled by Google.

Because that's just how copyright works. You can't erase attributions and redistribute without permission.

Browsers need to have maps from vendor prefixes to standardized way of doing things. If an upgrade path isn't possible, the page needs to throw a warning back to the originating server in a GET request at a well known endpoint.

Google doesn’t quite have that power - some of the things they have pushed have failed to gain traction, sometimes for very good reasons. For example, Object.observe was a proposal that Google themselves eventually unshipped from the Chrome after the JS ecosystem roundly rejected adopting the paradigms it enables, most notably for React’s unidirectional data flow (it always felt like a proposal meant specifically to optimize Angular). Google also backtracked on Web Components, choosing to revise the spec after some ideas became awkward when combined with the emergence of ES modules.

The other browser vendors play an incredibly meaningful role, as well as the frontend web developer community at large.

I can recommend to read this comment chain as well, IMO it shows the arguments of both sides very well (and avoids us having to re-argue this every time).