The evolution of the web, and a eulogy for XHTML2
This piece gets many things wrong --- or at least fails to present both sides of the argument.<p>WHATWG did not &quot;usurp&quot; 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.<p>There are technical reasons why HTML &lt;object&gt; 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 &lt;object&gt; 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 &lt;object&gt;.<p>The author misunderstands, or misrepresents, the WHATWG&#x27;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.)<p>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 &quot;yellow screen of death&quot;. 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 &quot;yellow screen of death&quot;. 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.)