Plan 2014

Table of contents

Introduction

The HTML Working Group has made much progress on HTML5 and related specifications. The HTML Working Group Chairs and the Protocols and Formats WG Chair have been asked by the W3C Team to provide a credible plan to get HTML5 to Recommendation status by 2014. Challenges remain in achieving this goal. We sought to produce a plan that achieves this date and that has minimal risk of delays from unexpected events.

We'd like to now propose our draft plan to the HTML Working Group for consideration. Here are the key points of our plan:

We invite the HTML WG, the Accessibility Task Force and the PF WG to review this plan with an open mind and provide feedback.

Progress

Year to date, we've managed to resolve approximately 600 bugs and 28 issues, many by amicable consensus.

As we announced on 23 April, at Ian Hickson’s request, we looked to change the editorial team for HTML5. We've put together an effective editorial team who are rapidly coming up to speed. We suffered a short term schedule impact for doing so, but felt it was the right decision to allow us to simultaneously get to REC and continue future work in HTML.

We've captured a number of proposed elements and attributes for HTML.next as well as number of efforts were started in order to produce proposals for HTML.next: examples include the WHATCG, the Web and TV IG and the Responsive Images CG.

We've moved development of the core HTML5 and HTML Canvas 2D Context documents to github. In the process, we've set up a branch that is updated hourly with the contents of the WHATWG specification. This facilitates cherry picking of changes into the HTML specification.

We identified a number of Decision Policy changes which we believe will lead to stabilization and more involvement with the Working Group.

We've achieved apparent, but as of yet unconfirmed, consensus on a set of CR Exit Criteria recommendations.

Remaining Challenges

The W3C CEO has asked us to contain the date for HTML 5.0 to obtain REC status within 2014.

We have 10 open issues, and approximately 300 outstanding bugs which arrived after Last Call closed, with more still coming in. We have 11 Formal Objections as well.

This presents a significant risk of infinite regress if we simply proceed to yet another Last Call in response to the previous Last Call, particularly if we remain open to allowing new issues to continue to be raised.

The current combination of a monolithic kitchen sink specification, Decision Policy, A11y Task Force, and Formal Objection process has led to a significant number of objections, and current difficulties in achieving consensus. More focus on proposal development is needed to move forward.

With all the above considered, we believe that if we were to introduce into this context a compressed schedule in response to the CEO’s push for a REC in 2014, this would inevitably lead to even more Formal Objections and schedule risk.

Proposed plan

Recognizing the pressures to ship a REC sooner -- possibly with less functionality -- than later, we are proposing a plan for taking a stable HTML5.0 specification to W3C Recommendation by the end of 2014, as well as a plan for taking an HTML 5.1 specification to W3C Recommendation by the end of 2016. In outline form:

As deferring work is common practice, we may simply need to cite ample precedents, and work on the messaging.

The W3C team has a proposal [member only link] which details how specs can proceed to REC with dependencies on specs that haven't completed.

Revised HTML 5.0 milestones

The following are revised milestones based on the above plan:

CR: 2012 Q4 LCf: 2014 Q3 PR: 2014 Q4 Rec: 2014 Q4

For CR, we begin in October 2012 by creating a draft HTML5.0 implementation report, which eliminates controversial or unstable features, and contains a listing of all the features in the current HTML5 specification, with information about:

which of the features have been implemented in browsers, and in which browsers

how stable each feature is

what the level of interoperability for each feature is

a list of at risk features

We also begin work on a systematic HTML5.0 Testing Plan, with the goals being:

identifying areas that are known to be interoperable and don't need further tests.

identify areas that are known not to be interoperable, and to be removed without the need for investing time in the creation of tests.

for the remaining areas: systematically determine which features we currently have test cases for systematically determine which features we still need test cases for



The initial draft of the HTML5.0 implementation report will be more of an outline than an actual report; at first it may be based more on qualitative assessments of features than on quantitative assessments. But as we get more test cases into the W3C Testing Framework, we will be able to collect more quantitative data on features, and to update the HTML5.0 implementation report, and evolve it into a much more quantitative assessment of all features in the specification. We should use the remains of the editor fund to hire extra resources for the html test suite task force.

Additionally, we will identify a date approximately three months before the completion of CR (and therefore in 2014 Q2) which will be the final date upon which extension specifications that obtain consensus and meet the CR exit criteria can be identified for folding into the core HTML specification.

HTML5.1 milestones

For HTML5.1, we can use milestones similar to those for HTML5.0.

HTML5.1 milestones ------------------ FPWD: 2012 Q4 LC: 2014 Q3 CR: 2015 Q1 Rec: 2016 Q4

During this process, we will encourage modularity as a preferred way to approach introducing new features into the 5.1 release.

So the combined timelines for HTML5.0 and 5.1 would look like this:

2012 2013 2014 2015 2016 ---------- ---------- ---------- ---------- ---------- HTML5.0 CR start ...CR, LC Rec ... ... HTML5.1 FPWD --- LC + CR ...CR Rec

Note that these dates are for the core HTML specification. While all documents will be ready to proceed to CR once the Formal Objections are processed, each can proceed at their own pace.

Relationship between HTML5.0, HTML5.1, and beyond

During the CR period for HTML5.0:

we determine which features are likely to meet the “Public Permissive” CR exit criteria,

we create a “stable HTML5.0” draft which includes just those “stable” features, and which omits the remaining “unstable” features

we create an HTML 5.1 editor’s draft which is a superset of the stable HTML5.0. “Unstable” features from HTML 5.0 and proposed features may be included in the HTML 5.1 draft.

... and the cycle repeats:

we again determine which features are likely to meet the “Public Permissive” CR exit criteria,

we create a “stable HTML5.1” draft which includes just those “stable” features, and which omits the remaining “unstable” features

we create an HTML 5.2 editor’s draft which is a superset of the stable HTML5.1. “Unstable” features from HTML 5.1 and proposed features may be included in the HTML 5.2 draft. We estimate that the FPWD for HTML 5.2 would be in early 2015.

Modularity

Consistent with the W3C’s Principles of Design , we propose a greater reliance on modularity as a key part of the plan to make faster progress. When we speak of modularity, we mean identifying specific features, either proposed or already existing in the spec, and advancing them as separate specifications. We believe there are some misconceptions about modularity and HTML5, so we'd like to address those before we cover how to apply it specifically.

HTML5 is good at modularity

There is a widespread belief that HTML5 is “bad at modularity”. It’s true that HTML5 originated is a large specification, and that it originated as a monolithic “kitchen-sink” spec with a grab bag of features. But HTML5 offers powerful hooks for extension specifications. It allows extension specs to define new elements, new attributes, new values for attributes that accept defined sets of keywords, and new APIs. This extension capability has been widely used.

Many technologies that were originally defined in HTML5 itself are now defined in separate specifications, either in the HTML WG or in other Working Groups, here are some examples:

Many specifications have been created consciously as extensions to HTML5, here are some examples:

And finally, some specifications that were initially developed standalone have been adapted as HTML5 extensions or features by reference:

SVG - SVG WG

MathML - Math WG

WAI-ARIA - PFWG

As can be seen from the list above, HTML5 has become vastly more modular over time. Many parts of HTML5 have been factored out. And both the HTML WG and other WGs make heavy use of the extension specification mechanism for new features.

Extension specifications are first-class citizens

Some believe that extension specifications are second-class citizens, or somehow “lesser” than the core HTML5 specification. On the contrary, the specifications in the list above are vibrant, active pieces of the Web platform, with significant implementation traction and community credibility. Many extensions recognized as having wide consensus are recognized as part of the default settings of the W3C Validator, so they have an equal footing in validation. In addition, we will work to find ways to promote these extensions as a part of a family of HTML5 specifications.

Modularity is the right thing to do

Some dispute whether modularity is technically desirable when specifying something as complex as the client-side Web platform. It may be debatable whether modularity has technical benefits on net. The reason why we are proposing it is for the social benefits that accrue from such an approach. Splitting out separate specifications allows those technologies to be advanced by their respective communities of interest, allowing more productive development of approaches that may eventually be able reach broader consensus.

Several times, the HTML WG Chairs ruled in favor of modularity to significant initial controversy. We had a long-running dispute whether HTML5 should adopt RDFa or Microdata as a syntax for embedding structured metadata, or both, or neither. This was a highly controversial topic generating much friction on both sides. The prevailing Change Proposal called for Microdata to be split out, and for RDFa to also remain a separate specification rather than being folded in. After some initial sniping, this ended the controversy; both specs continued to advance in peace. Similarly, the inclusion of Canvas was a highly controversial topic. In the end, the WG and the Chairs got agreement from Ian Hickson to split the 2D Graphics API of Canvas into a separate specification. This too generated initial controversy, as there had been an attempt at a competing spec. Once the controversy calmed down, the spec resumed development in relative calm.

We also have a number of potential “HTML.next” efforts that are actively proceeding along this direction:

These documents are proceeding along their own schedule, and with a separate set of editors, effectively offloading the work.

The evidence shows that placing technologies in their own extension specifications, while initially controversial in some cases, has proven to be a long-term benefit for peace and harmony in the end.

Other changes/notes

Open WG Issues

To prevent confusion, we've identified how each of the remaining open issues will be handled:

Extension Specifications

The following is an excerpt from section 2.2.3 Extensibility of the current HTML5 editor’s draft:

When vendor-neutral extensions to this specification are needed, either this specification can be updated accordingly, or an extension specification can be written that overrides the requirements in this specification. When someone applying this specification to their activities decides that they will recognize the requirements of such an extension specification, it becomes an applicable specification . The conformance terminology for documents depends on the nature of the changes introduced by such applicable specifications, and on the content and intended interpretation of the document. Applicable specifications MAY define new document content (e.g. a foobar element), MAY prohibit certain otherwise conforming content (e.g. prohibit use of <table>s), or MAY change the semantics, DOM mappings, or other processing rules for content defined in this specification. Whether a document is or is not a conforming HTML5 document does not depend on the use of applicable specifications: if the syntax and semantics of a given conforming HTML5 document is unchanged by the use of applicable specification(s), then that document remains a conforming HTML5 document. If the semantics or processing of a given (otherwise conforming) document is changed by use of applicable specification(s), then it is not a conforming HTML5 document. For such cases, the applicable specifications SHOULD define conformance terminology.

A list of extension specifications can be found on the HTML WG wiki.