Table of contents
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:
- Revise the draft HTML WG charter to indicate an HTML 5.0 Recommendation in 2014Q4 and an HTML 5.1 Recommendation in 2016Q4.
- Use Candidate Recommendation exit criteria to focus testing where it is advisable (e.g. new features), without wasting time on testing where it is inappropriate (such as when interoperability is already proven on the Web)
to manage the size and complexity of the specifications while reducing
social conflict within a constrained timeline:
- Gain agreement that the remaining open issues can proceed via extension specifications at first. Provide an opportunity to merge extension specifications back into the baseline spec upon getting WG consensus and after the extension specifications meet their Candidate Recommendation exit criteria.
- Welcome the option of extension specifications that don't merge back at all and instead proceed at different paces and possibly even with different Candidate Recommendation exit criteria.
We invite the HTML WG, the Accessibility Task Force and the PF WG to review this plan with an open mind and provide feedback.
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.
The W3C CEO has asked us to contain the date for HTML 5.0 to obtain REC status within 2014.
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.
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:
Split what was originally HTML 5.0 into an HTML 5.0 and an HTML 5.1, and considerably raising the bar on what issues and bugs we consider in the HTML 5.0 timeframe:
- For bugs: create a new bugzilla component for HTML 5.0 stable/CR versions of the specifications, and only allow bugs to be created or moved in/to this component that address interoperability issues or can be addressed by a non-substantive change to the specification.
For issues: require actual specification text to be published in the form of extension specifications first, and only after said text meets the exit criteria for CR, consider folding the result into the core specification.
To prevent unnecessary confusion, the HTML5 specification will drop explicit indications that any given extension is obsolete once an extension specification exists that has been published as a FPWD. Additionally, the W3C staff will watch for drafts being published and keep the W3C validator up to date as appropriate.
Issues that are raised that concern interoperability issues will be considered during as a part of HTML5.0, all others will be considered in the HTML 5.1 timeframe. As needed, split out controversial or unstable text into extension specifications. A detailed, issue by issue, list of proposals appears later in this document.
Verify with those that made the 11 current Formal Objections that they continue to support their objections. Close those that we can, and forward the remainder for immediate consideration by the Director. We encourage the Director to advocate Modularity as a solution whenever possible.
Proceed immediately after these objections are processed to CR on HTML 5.0 with Public Permissive proposed CR exit criteria
We think it is likely that the Working Group will make substantive changes to the document as a result of Candidate Recommendation Review. Therefore, in accordance with the W3C Process, we will return to a short Last Call before requesting to advance to Proposed Recommendation.
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.
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.
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:
- HTML Microdata - HTML WG
- HTML Canvas 2D Context - HTML WG
- HTML5 Web Messaging - Web Apps WG
- Web Workers - Web Apps WG
- Web Storage - Web Apps WG
- The WebSocket API - Web Apps WG
- The WebSocket Protocol - IETF HyBi WG
- Server-Sent Events - Web Apps WG
- WebRTC - WebRTC WG
- WebVTT - W3C Web Media Text Tracks CG
Many specifications have been created consciously as extensions to HTML5, here are some examples:
- HTML+RDFa - RDFa WG
- DOM Parsing and Serialization - Web Apps WG
- Shadow DOM - Web Apps WG
- Web Intents - Web Apps WG / Device APIs WG
- Polyglot Markup: HTML-Compatible XHTML Documents - HTML WG
- HTML5: Techniques for providing useful text alternatives - HTML WG
- HTML Editing APIs - HTML Editing APIs CG
- HTML Media Capture - Device APIs WG
- Media Capture and Streams - Device APIs WG / WebRTC WG
- Media Fragments URI - Media Fragments WG
- Encrypted Media Extensions - HTML WG
- Media Source Extensions - HTML WG
- many rel value specifications registered at the link type registry - Microformats
And finally, some specifications that were initially developed standalone have been adapted as HTML5 extensions or features by reference:
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.
- Charter changes
We propose replacing the Liaisons section in the Draft HTML WG Charter with the following:
The HTML Working Group should maintain a liaison with the following groups:
Community Groups, including but not limited to Web Hypertext Application Technology (WHATWG) Community Group, Responsive Images Community Group and HTML Editing APIs Community Group.
The HTML Working Group will consider proposals for future specifications from Community Groups, encouraging open participation within the bounds of the W3C patent policy and available resources.
- Decision Policy changes
While some changes have already been proposed, the process of producing this plan has identified a number of additional changes:
- Change the heading for the Second Last Call Process Additions to one reflecting CR instead.
- Extend the period of review for proposed changes from 72 hours to one week.
- Define a process for integrating extension specs during CR.
- Define a process for removing nominated at-risk features early in CR.
- HTML5 Specification status section changes
- Indicate that this specification is part of an Open Web Platform Family of specifications, linking to a page (possibly on a wiki) which more fully defines this relationship and links to an evolving set of specifications.
- Explicitly state that indications that a given construct is obsolete will be dropped once an extension specification defining that construct reaches FPWD
- Indicate the status of the Open WG Issues
- Lead test manager team role
A W3C staff position needs to be created, and filled, with the following responsibilities:
- Maintain the HTML5.0 implementation report
- Add HTML tests cases to the W3C Testing Framework
- Get test cases approved
- Collect test results and use them to provide quantitative data in the HTML5.0 implementation report
The negative tone of discussion has been an ongoing problem which has kept many potential contributors away from mailing lists and teleconferences. We therefore need to be more active in making it clear that anti-social behavior will not be tolerated in the HTML WG.
- Accessibility Task Force
The current joint PWFG and HTML WG task force is not operating as effectively as we need it to be operating. We recommend the following:
- Allow the Task force to propose and/or take ownership of documents such as extension specs that are be jointly produced by the HTML and PF Working Groups. Give the Task Force the authority to create willful violations (overriding of existing specification text) of the HTML5 specification, as long as they are clearly documented as such and communicated. We need to be tolerant of these inconsistencies, and give room (and time!) for the replacement of the editor and the extra encouragement to publish extensions specifications to bear fruit.
- Give Task Force Co-Chairs a clear mandate to expand participation and foster greater collaboration across different perspectives. In addition, the chairing arrangement is under review.
- Responsibility for the HTML5: Techniques for providing useful text alternatives document will remain in the HTML WG. The A11y TF and the editor of the alt-techniques document are encouraged to work directly with the editors of the HTML5 document to reduce identified differences, filing new bug reports as appropriate. We will revisit the responsibility of the document after the differences have been resolved to the extent possible.
- Update the HTML Accessibility Task Force Work Statement to reflect the above changes.
Open WG Issues
To prevent confusion, we've identified how each of the remaining open issues will be handled:
30 longdesc attribute
Allow the A11y TF the authority to produce an extension spec that defines a longdesc attribute. If such a specification obtains consensus and meets the proposed CR exit criteria by 2014Q2 it could be folded back into the core HTML spec by that time. This can be combined with a solution for issue 203 and/or with work on a purported replacement.
We ask those that oppose instating a longdesc attribute to focus on producing a better solution, and meanwhile not oppose those that wish to pursue longdesc via an extension spec or making progress towards demonstrating that it meets the identified CR exit criteria.
Revisit in 2013Q4. None of the proposals define
changes to the specification. Since those proposals have been
written, new editors have been named, they've updated the status
sections already, and the relationship with the WHATWG has already
changed. That relationship may change again or even several times
before we complete CR.
- Revisit in 2013Q4. None of the proposals define substantive changes to the specification. Since those proposals have been written, new editors have been named, they've updated the status sections already, and the relationship with the WHATWG has already changed. That relationship may change again or even several times before we complete CR.
164 hgroup element
Retain the current hgroup language in the spec. Note that a number of shipping browsers implement the syntax, but there is no currently known complete implementation of the semantics. Therefore, hgroup will be marked as an at-risk feature.
The procedure for early dropping of at-risk features may be applied to hgroup. As a result, if no reasonably complete implementations are available, it is likely that it will be dropped from the core spec early in CR.
Allow extension specs to be written that MAY define new document content, MAY prohibit certain otherwise conforming content (e.g. prohibit use of <hgroup>s), and MAY change the semantics of existing elements. If such a specification obtains consensus and meets the proposed CR exit criteria -- it could be folded back into the core HTML spec at that time.
185 drop pubdate attribute
Allow an extension spec to be written that defines a moddate and/or a pubdate attribute. If such a specification obtains consensus and meets the proposed CR exit criteria -- it could be folded back into the core HTML spec at that time.
194 full-transcript attribute
- Allow the A11y TF the authority to produce one or more extension specs that includes a full-transcript attribute. If any such a specification obtains consensus and meets the proposed CR exit criteria by 2014Q2 it could be folded back into the core HTML spec at that time. The A11y Task Force is encouraged to converge onto a single solution.
- Allow an extension spec to be written that defines the various semantics described by the Enhance HTTP request generation from forms change proposal. If such a specification obtains consensus and meets the proposed CR exit criteria -- it could be folded back into the core HTML spec at that time.
- Allow an extension spec to be written that defines an ilegend element and changes the semantics of the legend element. If such a specification obtains consensus and meets the proposed CR exit criteria -- it could be folded back into the core HTML spec at that time.
- Get the editors to apply the decision to Provide for canvas location and hit testing capability with an exposed Path object and related alterations to the 2d Context API.
- Allow the A11y TF the authority to produce an extension spec that defines an alt and longdesc attribute on the media element. Note: this could even be the same specification as the one for issue 30. If such a specification obtains consensus and meets the proposed CR exit criteria by 2014Q2 it could be folded back into the core HTML spec at that time.
206 meta generator exception
- Allow an extension spec to be written that may define additional attributes that affect the conformance of documents which don't include an alt attribute. If such a specification obtains consensus and meets the proposed CR exit criteria -- it could be folded back into the core HTML spec at that time.
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.