The recent formalisation of the ‘HTML split’ between the W3C and the WHATWG, is not news to those working in either group. Work continues pretty much as it has, prior to Hixie’s communication to the WHATWG.
HTML Implementation in Browsers
The reality is that browser implementation information of HTML will be similar if not the same up until the point where HTML5 is finalised at the W3C. There may be some minor differences due to the W3C spec not keeping up with changes to the WHATWG spec or points where not all browser vendors have agreed on the implementation details of a particluar feature. In the latter case it may be that the WHATWG spec or the W3C spec contains implementation information relevant to some but not all current implementations or a proposed implementation that has not actually been implemented by anybody.
It will be the case that as finalisation of HTML5 occurs at the W3C, the browser implementation information in it will become progressively out of date as new features are specced in the WHATWG HTML, implementation bugs arise and are fixed. Concurrently with the finalisation of HTML5 it is envisaged that work on HTML.next will commence at the W3C, taking HTML5 as its basis. It will likely be the case that HTML.next will mostly track the WHATWG spec on implementation details where browser vendors have indicated they intend to implement the WHATWG spec as written. This is not always the case now and will not be so in the future, for example some of the new additions to canvas contained in the WHATWG spec have not been agreed upon by browser vendors and further work is taking place between Apple and Microsoft and other stakeholders to agree upon the details, this work is occurring in the W3C HTML WG. If it is the case that the Canvas 2d context spec contains agreed upon implementation details that the WHATWG spec does not, then what should occur is the WHATWG spec changes to reflect such consensus. So let us not be fooled into thinking that the current and future specification of HTML is a one way street always leading from the WHATWG to the the W3C. So it may be that at moments in time implementation details in the current W3C HTML (whether that be HTML5 or HTML X) and WHATWG HTML diverge, but it will not be a permanent divergence unless either spec diverges from reality.
It is not the case that WHATWG spec always contains a realistic representation of what is implemented in browsers, it contains defined features that are not yet implemented by any browser even though they have been in the spec (and HTML5) for years. And it omits features implemented in browsers. The command element has been specced for years When Mozilla decided to implement the HTML5 context menu instead decided to use the unspecified (in HTML) <menuItem> element rather than implement the command element.
HTML Accessibility Implementation in Browsers
While the WHATWG claims its goal is to provide a canonical description of HTML and related technologies, it only contains a minimal description of how browsers should implement HTML support for assistive technology. The WHATWG have never shown any interest to my knowledge (note: anne van kesteren claims this is FUD, but have not seen anything from the WHATWG leadership to suggest otherwise and Hixie stated the HTML to accessibility API document was unecessary) in specifying the level of detail required for the interoperable implementation of accessible HTML. This work is being carried out at the in the W3C HTML WG as part of the ongoing HTML standardization effort. WHATWG leader Ian Hickson decided to fork HTML rather than include a link to it in the WHATWG HTML:
The W3C HTML specification includes a link to an incomplete document that contradicts this specification because of a working group decision from February 2011.
Author conformance requirements and advice
Much of the authoring conformance requirements and advice impacts the accessibility of the authored content. This is where things get less predictable. While requirements and advice in regards to HTML feature implementation in browsers is in essence dictated by what browsers will implement, how such features are to be used is not and consequently the differing HTML development processes between the W3C and the WHATWG have had most effect and will continue to do so.
To get author conformance requirements and advice on the how to use HTML into the WHATWG spec, or get it changed, you must convince Ian Hickson (Hixie). If Hixie does not agree with you it doesn’t go in or it doesn’t change. The W3C HTML working group does not work this way. You can present your arguments, research and data to the working group and whether information is added to or changed in W3C HTML is decided by the working group using a consensus process. And yes this can take longer than a simple Yay or Nay from Hixie, but I think the extra time is worthwhile.
Some examples
I have long argued that due to the almost complete lack of keyboard access to the the title attribute in browsers, the HTML specification should not include conformance requirements and authoring advice for the use of the title attribute that will result in inaccessible content. I provided information on this to the HTML WG and Hixie, (then) editor of HTML5:
- Advice in spec about annotations promotes inaccessible content
- Do not consider the title attribute as a possible conforming source for caption information for an image that lacks a text alternative
- Replace poor coding example for figure containing multiple images
Each of these proposals were considered and accepted by the HTML WG and the changes were made to HTML5 to reflect this. While at the WHATWG, Hixie, making no argument either way simply rejected the changes, resulting in further forking of HTML:
The W3C HTML specification omits a number of suggestions regarding using the
title
attribute, and makes using thetitle
attribute for captions non-conforming in certain specific cases, because of a number of working group chair decisions from March 2012: first, second, third.
Now I would appreciate ANYONE explaining how the splintering of authoring conformance requirements and advice being good for anyone? Is it good for users? developers? If not then who?
Conclusion
What has recently been reported as a split has in effect been happening for some time. If all you care about is how browsers implement or are expected to implement some aspects of HTML then you have little to worry about, both W3C HTML and WHATWG HTML will include pretty much the same information over time. The locus of the HTML accessibility work will continue to be at the W3C and in the HTML WG, the specification of how browsers implement HTML to support accesssibility, will continue in the W3C HTML working group. The development of author conformance requirements and advice based on real world implementations and direct participation from users will continue in the W3C HTML WG.
Is this HTML5?
The HTML living standard still claims to be HTML5, while the HTML living standard ‘developer edition’ still calls itself “HTML5 A technical specification for Web developers”, so if you are interested in how to use HTML to provide a better, more accessible user experience, then increasingly you will be in a quandary as to which set of rules to follow and which set of rules you are actually following. I think you know which one I would suggest…
Further Reading
- Mike Smith’s (aka @sideshowbarker) personal comments on the latest WHATWG vs W3C non-news
- W3C and WHATWG finalize split on HTML5 spec, forking ‘unlikely’
- Ian Hickson: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
- Steve Faulkner: Re: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
- Ian Hickson: Re: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
- Steve Faulkner: Re: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification