4 ms·

This piece gets many things wrong --- or at least fails to present both sides of the argument. WHATWG did not "usurp" the W3C. The W3C abandoned HTML developme

by roca 7y ago

This piece gets many things wrong --- or at least fails to present both sides of the argument. WHATWG did not "usurp" the W3C. The W3C abandoned HTML development by focusing on XHTML2, incompatible with HTML. This left an opening for someone to propose backwards-compatible extensions of HTML, since the W3C was explicitly not interested in that. WHATWG was formed to do this and produced HTML5. HTML5 was adopted by industry, XHTML2 was not. In an attempt to stay relevant, the W3C tried to stage a hostile takeover of HTML5. That attempt failed because the W3C had blown their credibility by that point. However there were still some advantages to having a W3C-approved HTML spec, so an agreement was reached where the W3C could approve the specs produced by WHATWG. There are technical reasons why HTML <object> was not suitable for audio and video elements. For example, media elements need to expose media-specific JS APIs (e.g. seek()), but the MIME type of an <object> can change over time due to URL loading and DOM attribute changes, which would mean that the interface exposed by the element would need to change unpredictably over time, which would be a nightmare for developers. Also, there were very nasty legacy browser compatibility constraints around (mis)use of <object>. The author misunderstands, or misrepresents, the WHATWG's spec design philosophy. Unlike the W3C, the WHATWG treated compatibility with existing Web content as essential. That means the WHATWG specifies existing browser behaviour where there is significant existing Web content that requires it. The W3C, on the other hand, tended to assume that Web developers pay attention to specs and that writing down conformance requirements would magically cause all Web content to be updated to satisfy them. Those assumptions are not true. (The idea that Web developers would migrate to XHTML2 because the W3C proclaimed it as the future was in the same vein.) XML syntax for HTML failed for various reasons but not because of the WHATWG or browsers, which always supported XML syntax for HTML. One major problem is ensuring that dynamically generated XML pages are always valid XML. It is very easy to have bugs so that under some conditions (e.g. malicious user input) the server outputs invalid XML and produces a "yellow screen of death". Common examples of those bugs were bugs that allowed the Unicode 0xFFFE or 0xFFFF code points to slip into the XML output, which are not allowed in valid XML. A similar problem is when users interrupt a partial download of an XHTML file; the file has unclosed tags, so a conforming browser will replace the partially loaded and rendered document with a "yellow screen of death". This is not what users or developers actually want. (This assumes the browser bends the rules to allow partial rendering in completely loaded and validated XHTML documents, which is something users and developers do actually want.)

jillesvangurp 7y ago
Exactly, browser manufacturers had a need for specifications that were of a higher quality than what W3C was producing in order to address (mostly) accidental implementation differences between different browsers. What was specified across existing specifications for html, css, and javascript was just not covering what was being shipped by browsers. And as these specifications were stuck in committees, browser developers had to just figure things out themselves. HTML 5 started out as an W3C position paper to start the work of creating a backwards compatible successor to HTML 4 backed by several browser developers. The proposal for this was rejected in favor of continuing work on the non backwards compatible XHTML 2. As these browser developers had a need for a spec, the WHATWG was formed to create what became HTML 5. Several years later when it became clear that their specification was the closest thing to describing what browsers actually do, W3C basically endorsed it as a recommendation. However, the WHATWG continues to drive work as it has been highly successful in producing the high quality specifications required to achieve the high levels of interoperability between the remaining browser engines. XHTML 2 gradually became redundant as most of the functionality that web site developers actually needed from browsers got absorbed by HTML 5. As browsers could implement spec changes as they were happening, within a few years of the working group forming, it had become a huge success in standardizing many new features. At the same time, many mobile browsers simply disappeared as Webkit (a fork of KTML by Apple) and the Chrome fork of Webkit by Google became the norm on mobile. This was important because many W3C working groups were dominated by people from the mobile phone and telecom industry seeking to control the standard for long forgotten things like WAP and the various mobile profiles of XHTML. Once decent browsers appeared on mobile (i.e. browsers that supported HTML 5), the need to continue to do work on XHTML 2 disappeared. Most of the companies that then dominated the mobile web were out competed by Google and Apple; neither of whom was a major mobile player at the time the WhatWG was formed. By the time W3C endorsed HTML 5, Android and IOS were dominating the mobile web to the point that even MS threw in the towel by first creating Edge (an html 5 browser with no backwards compatibility for IE specific stuff), and then recently just switching to Chrome entirely.

by roca 7y ago

jillesvangurp 7y ago

Exactly, browser manufacturers had a need for specifications that were of a higher quality than what W3C was producing in order to address (mostly) accidental implementation differences between different browsers. What was specified across existing specifications for html, css, and javascript was just not covering what was being shipped by browsers. And as these specifications were stuck in committees, browser developers had to just figure things out themselves. HTML 5 started out as an W3C position paper to start the work of creating a backwards compatible successor to HTML 4 backed by several browser developers. The proposal for this was rejected in favor of continuing work on the non backwards compatible XHTML 2. As these browser developers had a need for a spec, the WHATWG was formed to create what became HTML 5. Several years later when it became clear that their specification was the closest thing to describing what browsers actually do, W3C basically endorsed it as a recommendation. However, the WHATWG continues to drive work as it has been highly successful in producing the high quality specifications required to achieve the high levels of interoperability between the remaining browser engines. XHTML 2 gradually became redundant as most of the functionality that web site developers actually needed from browsers got absorbed by HTML 5. As browsers could implement spec changes as they were happening, within a few years of the working group forming, it had become a huge success in standardizing many new features. At the same time, many mobile browsers simply disappeared as Webkit (a fork of KTML by Apple) and the Chrome fork of Webkit by Google became the norm on mobile. This was important because many W3C working groups were dominated by people from the mobile phone and telecom industry seeking to control the standard for long forgotten things like WAP and the various mobile profiles of XHTML. Once decent browsers appeared on mobile (i.e. browsers that supported HTML 5), the need to continue to do work on XHTML 2 disappeared. Most of the companies that then dominated the mobile web were out competed by Google and Apple; neither of whom was a major mobile player at the time the WhatWG was formed. By the time W3C endorsed HTML 5, Android and IOS were dominating the mobile web to the point that even MS threw in the towel by first creating Edge (an html 5 browser with no backwards compatibility for IE specific stuff), and then recently just switching to Chrome entirely.