Hacker News Reader

Comment by goblin89 | Hacker News Reader

Not going into politics I personally favor WHATWG’s overall presentation of the spec, but I go to W3C’s rendition for one reason—they version the spec and publish a readable changelog[0] highlighting the key changes between versions.

In contrast, WHATWG’s officially recommended[1] ways of keeping up are commit history (quite messy), Twitter feed (primarily channeling commit history as it seems), and—I kid you not—manual diffing of Git revisions.

[0] https://www.w3.org/TR/2017/REC-html52-20171214/changes.html#...

[1] https://github.com/whatwg/html/blob/f8f9c6c222ce79c2f8df1855...

View on HN

The problem with the W3C version is that it isn't even a snapshot of any version of the WHATWG document. The W3C has modified it in some arbitrary ways which don't correspond to any "ground truth" in browser implementations.

A practical example: The W3C "spec" says that the <main> tag must only appear once in a document. WHATWG and browsers agree that multiple <main> tags are perfectly fine, albeit silly.

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.

That seems like something to note in a "best practices" guide/book, not in a document that describes how HTML is parsed.

Unless all major browsers agree on how <main> is parsed.

Then that's how it's parsed.

Exactly, there's a difference between a document for browser implementers and a document for end users/document authors.

No end users are going to read EITHER spec.

No end users are going to read EITHER spec.

As an end user/engineer I occasionally refer to either spec when something isn't clear otherwise. It was by referring to W3C and WHATWG specs that I wrote a text-synced audio player a few years ago, for example.

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?

> WHATWG’s officially recommended[1] ways of keeping up are commit history (quite messy), Twitter feed (primarily channeling commit history as it seems), and—I kid you not—manual diffing of Git revisions.

That is mostly meaningful for browser makers and Web authors that want to interact with the development of the HTML specification.

Web developers that simply want to make things are rather encouraged to search MDN and caniuse.com[0], which provide information about the availability and potential quirks of HTML features across browsers, and link to sections of the appropriate specifications.

[0]: https://github.com/whatwg/html/blob/f8f9c6c222ce79c2f8df1855...

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.

Here is my reply to a similar concern last time this came up: https://news.ycombinator.com/item?id=15927130.

Reply on news.ycombinator.com