Plan 2014

Table of contents

Show TOC
Close

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:

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

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:

... and the cycle repeats:

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:

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

Charter changes

We propose replacing the Liaisons section in the Draft HTML WG Charter with the following:

Liaisons

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
Civility

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:

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

Related searches:
extension criteria proposed working stable
gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.