Completa ratificación del HTML 5 será oficial alrededor de 2014

Aunque no lo crean y a casi un consenso de la comunidad de programación, prácticamente el HTML 5 es considerado como los mejores día de programar en internet, pero aun no está estandarizado de manera oficial.

El grupo de trabajos del Consorcio del World Wide Web (W3C) han presentado un plan de aprobar una especificación HTML5 estable antes de finales de 2014. El plan propone definir formalmente un conjunto estable de características como HTML 5.0

Plan 2014

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:

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)

Use modularity 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.

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 theResponsive 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:

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, drop explicit indications that any given extension is obsolete once an extension specification exists that has been published as a FPWD. 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.

Allow extension specs to proceed at their own pace. Examples: HTML/XHTML Compatibility Authoring Guidelines, HTML Canvas 2D Context, and HTML Microdata.

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 inter-operable 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 but with the “unstable” features included instead of omitted, and also with any new proposed features included

… 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 superset of the stable HTML5.1 but with the “unstable” features included instead of omitted, and also with any new proposed features included. 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:

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:

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:

Encrypted Media Extensions

Media Source Extensions

HTML Responsive Images Extension

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:

LiaisonsThe 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 small 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.

Open a bug to define a process for reincorporating extension specifications back into the core specification. This bug needs to be addressed before the first extension spec achieves CR exit criteria, and no later than the end of 2013. The process will require extension specs to meet CR exit criteria and to have HTML WG consensus for reintegration, but it will not categorically rule out extension specs that define new or additional features.

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.

Move responsibility for the HTML5: Techniques for providing useful text alternatives document from the HTML WG to the A11y TF.

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.

151 whatwg references

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. Identify the semantics as an at risk feature.
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

Retain the current pubdate attribute in the spec. Identify it as an at risk feature.
Allow an extension spec to be written that defines a moddate 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 an extension spec that includes full-transcript. 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.

195 form http request

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.

200 legend placement

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.

201 canvas-fallback

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.

203 media descriptions

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.

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 specificactions, 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 aconforming HTML5 document does not depend on the use of applicable specifications: if the syntax and semantics of a given conforming HTML5 document 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.

El plan parece estar motivado por el hecho de que a pesar de esfuerzos como el nombramiento de los nuevos co-editores a finales de julio 2012 , siguen siendo demasiadas grande las áreas en construcción, y no hay demasiada variación en el grado de desarrollo de muchos otros, para completar todo para el año 2014.

Pero a pesar de este “pequeño” a estas alturas muchos entienden que establecer a la mala una estandarización como lo fue con el HTML 4, ya no es necesariamente urgente, debido a la gran aceptación del borrado que ha sido utilizado de manera global en la comunidad de programación. Obviamente como programador debo decirles que una estandarización de un lenguaje de programación trae la ventaja de que el código de desarrollo de cualquier proyecto saldrá limpio y eficiente.

Basado en la pasada premisa, si HTML 5 con un simple borrado ha tenido tanto éxito y ha cambiado el internet moderno de hoy, pueden imaginarse que nos espera cuando finalmente se estandarice por completo el HTML 5.