html

> 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...

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...

> And yet, we don't get things like that changes page from the WHATWG version. (Unless you want to dig through the whole commit history) So far we've done our best to keep a really readable, tidy Git commit log, which should help with understanding changes: https://github.com/whatwg/html/commits/master If you omit the "Editorial:" or "Meta:" commits, I think it's actually at a similar level of detail as the W3C fork's changes log. (Not completely; scrolling through I do see a number of commits that wouldn't be relevant.) But the W3C fork has only managed to copy-and-paste a small subset of our changes, so indeed, the changes log for the last year of work at the WHATWG will be somewhat daunting compared to the small subset they managed to copy over. There may be room for someone to compile a higher-level "this week/month/year in the HTML S

I don't really know what process the W3C fork of our work uses for removal, if any, but you can learn more about how features get removed in the (WHATWG) HTML Standard per our working mode: - https://whatwg.org/working-mode#removals - https://whatwg.org/faq#removing-bad-ideas In short, I think it's important to distinguish between conformance and removal from browsers. Removal from browsers is a big deal and, as per those links, is only done when it's not going to break the web, or when the benefits are very high (e.g. security issues). Removal from being conformant just reflects the evolution of best practices. See also https://github.com/whatwg/html/blob/master/FAQ.md#how-are-de...

The biggest weirdness about it was that it was essentially a parser macro, not an element. That is, at parse time, it expanded into a form/label/hr/input set of elements into the token stream. Super-bizzare. See the removal patch at https://github.com/whatwg/html/commit/5c44abc734eb483f9a7ec7....

I haven't looked at the W3C fork of our work, but in the actual HTML Standard (maintained at the WHATWG), menu was not completely removed---just the mostly-unimplemented context menu feature. We left menu as a semantic alternative to ol/ul for menu-like lists. See more at https://github.com/whatwg/html/pull/2742 --- For more on removals within the WHATWG process, see: - https://whatwg.org/faq#removing-bad-ideas - https://whatwg.org/working-mode#removals There's also the case of things like marquee, which are not removed, but just marked as obsolete and something that web developers must not use. (Which in practice means that conformance checkers like https://checker.html5.org/ are required to complain about them; it doens't mean there's some godlike web-developer-enforcement committee going around preventing you from writing code that use

https://github.com/whatwg/html/blob/master/FAQ.md What parts of the standard are stable? The whole standard is more or less stable. There are some parts of it that describe new technologies that have not yet been implemented everywhere, but at this point those additions are only added after the design itself is pretty stable. Such additions must also have the support of two or more implementers, per our working mode[1]. Why are there no stable snapshots, or versions, of the standard? In practice, implementations all follow the latest standard anyway, not so-called "finished" snapshots. The problem with following a snapshot is that you end up following something that is known to be wrong. That's obviously not the way to get interoperability! This has in fact been a real problem at the W3C, where mistakes are found and fixed in the editors'

Well, in my paper, like you, I'm criticizing (tag omission in) HTML5's table content models, and discourage aggressive use of it ([1]), so probably I'm not the one to defend it ;) Even the HTML specification text itself got its tables wrong ([2]; also explained in [1]). [1]: <http://sgmljs.net/docs/html5.html#start--and-end-element-tag... [2]: <https://github.com/whatwg/html/commit/6e305c457e42276bf275b8...

There's zero lock-in unless you want to use Hangouts. Or Google Earth. Or Inbox. Not everything is standardized, sadly. Even the things that are ... well, https://bugs.chromium.org/p/chromium/issues/detail?id=690195 is an example from just earlier today where Chrome went to implement a spec, decided what the spec said was not convenient, and just implemented something else without bothering to raise a spec issue or anything. See https://github.com/whatwg/html/issues/2568 for the resulting lack of interop that the standards now have to sort out. This doesn't always happen, of course, but it happens often enough. Anyway, the Chrome team itself is, by and large, pretty good to work with (some exceptions like their "let's force-install this on unwitting users' computers" marketing deals notwithstanding). Other parts of Google are very m

> In our current code base we have more workarounds for FF bugs than any other browser, and some of them are pretty nasty. e.g. monkey patching `getComputedStyle` to get around this: https://bugzilla.mozilla.org/show_bug.cgi?id=548397 In that case, Blink and WebKit are changing to Firefox (and Edge)'s behavior, because it makes more sense. https://github.com/whatwg/html/issues/1813