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