W3C

Some issues with the W3C. Not really exhaustive.

• Restrictive copyright
• Forks rather than cooperates
• Main publications on TR/ are stale and cause confusion
  • https://bugzilla.mozilla.org/show_bug.cgi?id=688878#c6
  • https://bugzilla.mozilla.org/show_bug.cgi?id=505115#c141
  • http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/1207.html
  • https://critic.hoppipolla.co.uk/showcomment?chain=1232
  • http://lists.w3.org/Archives/Public/public-w3process/2014Sep/0081.html
  • https://github.com/emscripten-core/emscripten/pull/8849#issuecomment-505263102
  • ?? many versions of canvas
• Has a Process that can lead to working groups doing bad testing (just be able to meet W3C process requirements for transitioning from Candidate Recommendation to final W3C Recommendation, and the test suite cannot be living when the rules are strictly applied)
• CSS modularization (When designing the Fullscreen/<dialog> stacking model, the lack of a living standard spec for CSS that represented the current cutting edge status meant that features of CSS that were may have been overridden by one spec (e.g. CSS regions) were used by the proposal, without the implications being understood. (Specifically, it was suggested that CSS regions redefined how the containing block mechanism works; in general, without knowing what all the relevant specs are, there is no way to be sure that no other spec does in fact modify some underlying concept.))

History

Pre-WHATWG

In December 1997, HTML 4.0 was published as a W3C Recommendation. In February 1998, XML 1.0 is published as a W3C Recommendation. The same year, the W3C held a workshop about Shaping the Future of HTML:

Is HTML 4.0 the last HTML? Does XML mean the end of HTML? Has W3C given up on HTML?

[...]

In discussions, it was agreed that further extending HTML 4.0 would be difficult, as would converting 4.0 to be an XML application. The proposed way to break free of these restrictions is to make a fresh start with the next generation of HTML based upon a suite of XML tag-sets.

Reformulating HTML as XML was published as a Working Draft in December 1998, and later became known as XHTML 1.0.

Separately, the W3C worked on a new version of web forms, called XHTML Extended Forms (August 1999), later renamed to XForms, which was by design not backwards compatible with HTML forms. The introduction of the draft says:

After careful consideration, the HTML Working Group has decided that the goals for the next generation of forms are incompatible with preserving backwards compatibility with browsers designed for earlier versions of HTML. It is our objective to provide a clean new forms model (“XHTML Extended Forms”) based on a set of well-defined requirements. The requirements described in this document are based on experience with a very broad spectrum of form applications.

In April 1999, the W3C published a Working Draft of Modularization of XHTML, later known as XHTML 1.1, which didn’t introduce new features, but split the DTD into modules for the purpose of enabling subsetting and extending XHTML.

In August 2002, the W3C published a Working Draft of XHTML 2.0, which says in its introduction:

XHTML 2 is a markup language intended for rich, portable web-based applications. While the ancestry of XHTML 2 comes from HTML 4, XHTML 1.0, and XHTML 1.1, it is not intended to be backward compatible with its earlier versions.

The direction at the W3C at the time was thus to not work on HTML, but instead focus on new markup languages (XForms and XHTML 2.0) that are explicitly not backwards compatible with HTML or even XHTML 1.x.

WHATWG is formed

In June 2004, the W3C held a workshop on Web Applications and Compound Documents, where Mozilla and Opera proposed to extend HTML in a backwards compatible way. What happened here is well explained in Henri Sivonen’s Master’s Thesis An HTML5 Conformance Checker:

The Mozilla/Opera Joint Position Paper

The balance of power in the W3C had shifted from traditional desktop browser vendors to various other interest groups such as makers of software for mobile walled gardens and developers of “rich client” technologies that could be deployed on intranets but that were not used by the general public on the Web. This had led to a situation where the focus was more on the “Semantic Web”, “Web Services” and “Mobile Web” than on what is usually considered “the Web”. As a result, the development of the Web itself had been neglected.

In June 2004, the W3C held a workshop on Web Applications and Compound Documents. The Mozilla Foundation and Opera Software – the two most active browser vendors in the W3C at the time – submitted a joint position paper noting the “rising threat of single-vendor solutions” and calling for seven principles to be followed in the design of Web Applications Technologies. (At the time Microsoft – a notable browser vendor itself – was pushing a single-vendor solution code named Avalon and Apple was catching up having entered the market only recently.)

The first one of the seven principles in the Mozilla/Opera position paper was “Backwards compatibility, clear migration path”. The transition from HTML 4 to XHTML 1.0 had not worked out smoothly as discussed earlier. In addition, XForms, the W3C’s successor for HTML forms, did not provide backwards compatibility or a clear migration path. Moreover, the HTML working group was working on XHTML 2.0, which was designed to be incompatible with XHTML 1.x, even though the transition to XHTML 1.x served as application/xhtml+xml was not complete.

The position paper called for well-defined error handling – something that had never been addressed for HTML. The paper took a position in favor of graceful recovery (as in CSS) and against the Draconian error policy of XML.

The paper called for every feature to be backed by a practical use case and for the specification process to be open. This was in contrast with including features that are “nice to have” and making decisions on the W3C’s member-only mailing lists.

The paper took a position against device-specific profiles. This was in direct contrast with the Modularization of XHTML as well as mobile profiles of other W3C deliverables such as Scalable Vector Graphics (SVG). The paper also took a position more favorable to scripting (JavaScript in practice) than what has been the general line in the W3C.

[...]

The WHATWG is Formed

The proposal presented by Opera Software and the Mozilla Foundation was not well received at the W3C. At the end of the second day of the workshop, a poll was held on the topic of the joint position paper: whether the W3C should develop extensions to HTML, CSS and the DOM as proposed. Of the 51 attendees of the workshop, 8 voted in favor of the motion and 11 voted against. When the motion was slightly reformulated, 14 voted against.

Two days after the vote at the workshop, The Web Hypertext Applications Technology Working Group (WHATWG) and its public mailing list were publicly announced. The group was described as “a loose, unofficial, and open collaboration of Web browser manufacturers and interested parties”. The stated intent was creating specifications for implementation in “mass-market Web browsers, in particular Safari, Mozilla, and Opera”.

The initial (invite-only) membership of the WHATWG consisted of individuals affiliated with Apple, Mozilla and Opera Software. (Ian Hickson, the editor of the WHATWG specifications, later moved to Google.) However, in the view of the Web held by the WHATWG, there is also a fourth mass-market browser: Microsoft’s Internet Explorer – the leader in market share. Microsoft has not been participating in the WHATWG despite having been invited. The publicly stated reason was that the WHATWG lacked a patent policy. Dean Edwards, a Internet Explorer expert not affiliated with Microsoft, joined the WHATWG later.

Even though the group of WHATWG members is invite-only, anyone is allowed to join the WHATWG mailing list and contribute technically, which makes the process open. [...]

The formation of the WHATWG was a turning point for HTML. Mozilla, Opera and Apple were interested in working together to extend HTML but had to do so outside the W3C.

The two main WHATWG specifications were Web Applications 1.0 and Web Forms 2.0. An earlier version of Web Forms 2.0 was called Proposed XHTML Module: XForms Basic; it was, essentially, taking features of XForms and making them backwards compatible with HTML 4. Web Forms 2.0 was later folded into the Web Applications 1.0 specification, which was later renamed to HTML5 (May 2007), and again later to just HTML (January 2011).

New W3C HTML WG

The W3C took note that browser vendors were ignoring their work on XForms and XHTML 2.0 and were instead focusing on implementing the WHATWG proposals. In October 2006, Tim Berners-Lee wrote in his blog post Reinventing HTML:

Some things are clearer with hindsight of several years. It is necessary to evolve HTML incrementally. The attempt to get the world to switch to XML, including quotes around attribute values and slashes in empty tags and namespaces all at once didn't work... The plan is to charter a completely new HTML group. Unlike the previous one, this one will be chartered to do incremental improvements to HTML, as also in parallel xHTML.

In November 2006, Ian Hickson proposed a charter for the new HTML Working Group on the www-archive mailing list:

Mission

This group will continue the evolution of HTML by maintaining, and producing incremental revisions to, the HTML, XHTML, and DOM HTML languages and APIs.

[...]

Relationship to the WHAT Working Group

The Working Group is expected to work in collaboration with the WHATWG to produce identical specifications, preferably by having the same editor. This collaboration may cease if the two communities do not agree on technical matters.

In March 2007, the new HTML Working Group is chartered. The charter reads:

The mission of the HTML Working Group, part of the HTML Activity, is to continue the evolution of HTML (including classic HTML and XML syntaxes).

[...]

This group will maintain and produce incremental revisions to the HTML specification, which includes the series of specifications previously published as XHTML version 1. Both XML and 'classic HTML' syntaxes will be produced.

In May 2007, the WHATWG specification is renamed to HTML5, and the W3C also publishes HTML5 that is identical from the table of contents onward. Ian Hickson was editor of both specifications.

In January 2008, a First Public Working Draft of HTML5 is published.

In the years to come, the W3C HTML working group made decisions that the WHATWG disagreed with, which resulted in the two specifications deverging. The W3C also favored publishing multiple separate specifications, e.g. the canvas 2d context and Web Workers were their own specifications at the W3C, while the WHATWG favored a single big kitchensink specification. The WHATWG HTML standard says in its History section:

For a number of years, both groups then worked together. In 2011, however, the groups came to the conclusion that they had different goals: the W3C wanted to publish a "finished" version of "HTML5", while the WHATWG wanted to continue working on a Living Standard for HTML, continuously maintaining the specification rather than freezing it in a state with known problems, and adding new features as needed to evolve the platform.

Since then, the WHATWG has been working on this specification (amongst others), and the W3C has been copying fixes made by the WHATWG into their fork of the document (which also has other changes).

Forking

This is an extract of an e-mail sent in the context of complaining about the W3C forking the 2D Canvas part of the HTML spec. The observation was that while the fork of the WHATWG version meant the W3C was publishing one redundant copy, the situation just within the W3C was actually a lot worse:

Here's the list of all the 2D Context API specs I could find at the
W3C as of March 4th 2014:

• http://dev.w3.org/2006/canvas-api/canvas-2d-api.html
• http://www.w3.org/TR/2008/WD-html5-20080122/#the-2d
• http://www.w3.org/TR/2008/WD-html5-20080610/the-canvas.html#the-2d
• http://www.w3.org/TR/2009/WD-html5-20090212/the-canvas-element.html#the-2d-context
• http://www.w3.org/TR/2009/WD-html5-20090423/the-canvas-element.html#the-2d-context
• http://www.w3.org/TR/2009/WD-html5-20090825/the-canvas-element.html#the-2d-context
• http://www.w3.org/TR/2010/WD-2dcontext-20100304/
• http://www.w3.org/TR/2010/WD-2dcontext-20100624/
• http://www.w3.org/TR/2010/WD-2dcontext-20101019/
• http://www.w3.org/TR/2011/WD-2dcontext-20110113/
• http://www.w3.org/TR/2011/WD-2dcontext-20110405/
• http://www.w3.org/TR/2011/WD-2dcontext-20110525/
• http://www.w3.org/TR/2012/CR-2dcontext-20121217/
• http://www.w3.org/TR/2012/WD-2dcontext-20120329/
• http://www.w3.org/TR/2012/WD-2dcontext-20121025/
• http://www.w3.org/TR/2012/WD-2dcontext2-20121217/
• http://www.w3.org/TR/2013/CR-2dcontext-20130806/
• http://www.w3.org/TR/2013/WD-2dcontext2-20130528/
• http://www.w3.org/TR/2013/WD-2dcontext2-20131029/
• http://dev.w3.org/html5/canvas-extensions/
• http://dev.w3.org/html5/2dcontext-LC/
• http://dev.w3.org/html5/2dcontext/
• http://www.w3.org/TR/2dcontext/
• http://www.w3.org/TR/2dcontext2/
• http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas/
• http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/
• http://www.w3.org/html/wg/drafts/2dcontext/master/

Note that the first one has "2006" in the URL, is undated, says
copyright "2004", and references a draft from 2009. So the dates in
the URLs aren't very useful in determining whether they're up to date
or not. Then, notice the bottom seven, all of which seem to have some
claim to being the "latest" version. Four of them are dated March 4th
2014 (today)!

I actually couldn't tell you which version an implementor should look
at to get the latest information if they wanted a W3C reference. They
contradict each other (e.g. different methods are differently named
even amongst the various editors' drafts -- and that's not even
comparing them to the WHATWG spec, it's the W3C specs that contradict
each other here). Also, they all seem to be missing cross-references
to key terms (e.g. what does "fully decodable" mean? It's underlined,
indicating it's a link, but it isn't actually a link).

 In April 2014, Ian Hickson sends an email to the www-archive mailing list with the subject “Re: W3C vs WHATWG specs”, partially quoted below.

The W3C says "Forking a specification imposes high costs, and is therefore not recommended" (http://www.w3.org/2013/09/html-faq). But then they do it. Over and over again.

[...]

In the case of the WHATWG specifications, the licenses allow broad re-use, so that implementors can copy-and-paste text into their comment blocks, so that tutorial writers can copy-and-paste text into their documentation, so that experiments we haven't considered can spring up without inhibition, and so that, if the WHATWG stops being a good steward (like the W3C stopped being a good steward in the early 2000s), the next group of spec editors doesn't have to start from scratch.

However, forking and competing? That's not why the spec is reusable. It's plagiarism. Yes, I use that word intentionally. Taking someone else's work or ideas and passing them off as one's own.

W3C HTML5 Recommendation

In October 2014, HTML5 is published as a W3C Recommendation.

In October 2015, work on HTML at the W3C moved to the Web Platform Working Group; the HTML Working Group charter was not renewed.

In January 2016, Anne van Kesteren, one of the editors of the WHATWG HTML standard, writes on his blog:

The W3C has forked the HTML Standard for the nth time. As always, it is pretty disastrous:

• Erased all Git history of the document.
• Did not document how they transformed the document. Issues of mismatches have already been reported and it will likely be a long time, if ever, before all bugs due to this process are uncovered, since it was not open.
• Did not discuss plans with the wider community.
• Did not discuss plans with the folks they were forking from.
• Did not even discuss plans with the members of the W3C Web Platform Working Group.
• Erased the acknowledgments section.
• Erased the copyright and licensing information and replaced it with their own.

So far this fork has been soundly ignored by the HTML community, which is as expected and desired. We hesitated to post this since we did not want to bring undeserved attention to the fork. But we wanted to make the situation clear to the web standards community, which might otherwise be getting the wrong message. Thus, proceed as before: the standards with green stylesheets are the up-to-date ones that should be used by implementers and developers, and referred to by other standards. They are where work on crucial bugfixes such as setting the correct flags for <img> fetches and exciting new features such as <script type=module> will take place.

If there are blockers preventing your organization from working with the WHATWG, feel free to reach out to us for help in resolving the matter. Deficient forks are not the answer.

— The editors of the HTML Standard

The W3C continued to work on their fork. In November 2016, HTML 5.1 reaches W3C Recommendation. In December 2017, HTML 5.2 reaches W3C Recommendation.

WHATWG IPR Policy

Also in December 2017, the WHATWG gained a patent policy:

The WHATWG has been going great since it began in 2004, but without participation from all the browser engine implementers, was only partially meeting its goals. Over the last year, engineers and attorneys from the organizations behind Blink, Edge, Gecko, and WebKit have worked together to find a way forward that works for all the stakeholders.

What’s happening?

The organizations behind the four major integrated browser engines — Apple, Google, Microsoft, and Mozilla — have developed an Intellectual Property Rights (IPR) Policy and governance structure for the WHATWG. This enables more people to collaborate on Living Standards.

The W3C reacted to this as follows:

Earlier today, the WHATWG announced a new organization structure. W3C is flattered that WHATWG has adopted many shared features that are extremely positive for the web community. Among the features of the revised organization (some of which have happened prior to this announcement) that I think are excellent are:

• A Royalty-Free patent policy aligned with the W3C Patent Policy
• The notion of having a Review Draft (which the WHATWG is using for their patent commitments)
• The notion that features only go into the Living Standards if they have multiple implementation commitments and tests
• Continued partnership between W3C and WHATWG on testing
• Permissive specification licensing with attribution (CC-BY)
• A code of conduct

The new WHATWG Steering Group invited me to meet with them earlier this month. They shared their motivation for their new structure. Both organizations are motivated to build a stronger partnership between WHATWG and W3C, and the Steering Group and W3C plan to work on this. We welcome and look forward to that conversation.

In May 2018, the W3C held their annual Advisory Committee meeting, where the relationship with the WHATWG was discussed. In the blog post W3C strategic highlights for spring 2018 and Advisory Committee meeting, Jeff Jaffe reports:

Our partnership with WHATWG

W3C management shared a proposal for a joint workmode with WHATWG on HTML, that was developed with the WHATWG Steering Group, and seeks to organize a partnership that has had ebbs and flows over a period of more than a decade. A set of terms were developed, but W3C management had not had an opportunity to socialize it, or get feedback, reaction, and support. A large number of people came to the microphone with diverse viewpoints. There was general support for the overall direction, but quite a few important suggestions about how to make the proposal even better were made and need to be further developed before broader socialization.

In July 2018, a Review Draft of the WHATWG HTML standard is published, which is the first time the WHATWG provides patent protection for the HTML standard. Patent protection has been one of the stated reasons why the W3C have forked WHATWG standards.