annevk

That's a bit of a stretch. This is only relevant to legacy APIs and only when all implementations are in agreement, which is quite the rarity.

I'm not sure where you got this impression, but it's wrong. https://whatwg.org/working-mode stipulates the requirements on additions. That's quite a bit different from a set of wishes.

And there's a lot of cleanup of legacy APIs happening too. E.g., removal of the isindex tag and deprecation of AppCache.

I'm not sure I get the distinction. As for curl, it doesn't follow any standard which seems worse, but does at least helpfully demonstrate that the RFCs cannot be implemented by major clients.

What do you mean by non-HTTP? It handles URLs whose scheme is not http(s): just fine...

Indeed, having worked for Opera during the time where we implemented HTML5-compliant parsing, the net result was that we fixed a bunch of site compatibility issues. Implementing it made competing with other browsers easier. (And as you say, parsing HTML is complex, but the rest of the web platform is vastly more so.)

FWIW, the HTML Standard (not the DOM Standard) does include CanIUse information in a sidebar, to help with this. I'd like to include this into other WHATWG standards, but it hasn't really happened yet. I'd expect most web developers to use MDN and StackOverflow though, as you say.

I adjusted the post to take your feedback into account. Thanks!

It originally said "nay" and someone convinced me to change it to "née" which means nothing like "nay". I changed it back.

We cannot change the way <img> is parsed. See e.g. http://software.hixie.ch/utilities/js/live-dom-viewer/ for the tree you get with that markup. It's not what you expect.

Querying the pixel density of the device is not the same as describing the pixel density of the resource. This has been a common misconception in the discussion of this feature.

Because it is way more verbose and does not address the pixel density case.

The algorithm actually picks the resource you would expect there so that is a bug in the note. Filed a bug:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17057

You are assuming browsers implement a particular version of HTML. They do not. I work for a browser vendor (Opera) and what actually happens is that we keep getting closer to interoperability with each release. I.e. add support for EventSource, fix several bugs in the HTML parser, etc.

Software (and in particular the browser market) is not the same as a screwdriver. You do not bring it to market once and it is ready. It incrementally evolves over time and keeps getting better and better (when done right).

To counter Orwellian developments we have version control: http://html5.org/tools/web-apps-tracker

The basic idea is that the software (browsers, validators, editors), the specification, and common practice, all evolve together. This is how the web has evolved so far. We are simply acknowledging it.

I am a Member of the WHATWG and one of the persons that pushed for this change. We try not to snipe at the W3C. What happened was that HTML5 was used to mean a lot more than HTML5-the-spec in practice. The W3C embraced this and designed a logo around this concept. Now that the W3C was on board with calling e.g. CSS HTML5 we thought we could safely carry out a move we had wanted to make at the end of 2009. Namely dropping the 5 from HTML5 since HTML has no versions. It is a continuously evolving language.

The img element has baseline formats. GIF/JPEG pretty much from the start and now also PNG. If these formats were not there the img element would never have worked.