This blog is constructed from W2C
website posting for last 6 months, CIO.com reviews & couple of Blogs I
refer for HTML 5. This is a reference point for me as well for some dates etc. Not
my copyright but belongs to above mentioned authors & organizations. This
is just a data representation in a context. Please contact me in case any issue on HTML 5 at Ravindrapande@gmail.com
The Worldwide Web Consortium (W3C)
last week announced it will finalize HTML5 by 2014 and HTML 5.1 in 2016. With
significant challenges ahead, the W3C laid out a tentative implementation plan.
Should the plan be approved by the HTML Working Group the W3C will see 15 years
of work culminate in not only HTML5.0 but its successor 5.1 as well.
The reasoning behind announcing two
specs is the result of a different approach to the problems and setbacks the
W3C has faced in the past. The W3C plans to step back from what it has dubbed a
monolithic "kitchen sink" method with a grab-bag of features. Moving
forward it will rely more on modularity in an effort to prevent setbacks and
delays.
"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." -- Worldwide Web Consortium
Originally HTML5 included many
pieces that have now been turned into their own specifications including Web
Storage, Web Workers and the WebSocket Protocol. This approach will allow the
W3C to move any unstable elements into the HTML 5.1 spec, thereby limiting what
is in HTML5. With this approach the W3C can focus on making HTML5's current features
interoperable between browsers and stable--something they have been working on
for quite some time.
"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" -- Worldwide Web Consortium
W3C's
HTML5 Proposed Plan Outline
- 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.
Source: HTML5 Plan 2014 - W3C
If its plan is approved, the W3C
says HTML5 should reach Candidate Recommendation status, one step closer to
standardization, in the final quarter of this year.
HTML5
Progress and Setbacks
With 10 open issues, approximately 300
outstanding bugs and 11 formal objections it looks like the W3C has a tough
hill to climb. That said, year to date the W3C says it has tackled more than
600 bugs and 28 issues. It also faced some challenging staffing issues in 2012
when Ian Hickson stepped down from his role as HTML5 Specification Editor to
concentrate on other technologies at the Web Hypertext Application Technology
Working Group (WHATWG).
For open issues have look at http://www.w3.org/html/wg/tracker/issues/open
Since Hickson's departure, the W3C has brought aboard 4 new editors to the
HTML 5 editorial team in an effort to keep things moving forward. The new editors were announced on Wednesday by
HTML Working Group co-chair Paul Cotton in a message posted to the W3C's public
HTML mailing list.
They are Travis Leithead and Erika
Doyle Navara, both Microsoft employees; Ted O'Connor, an Apple employee; and
Silvia Pfieffer, an independent consultant whose company, Ginger Technologies,
specializes in HTML video.
Cotton gave no specific explanation
for any of the appointments, saying only, "After evaluating all the
applications, we chose the above HTML5 editorial team based on the individual
qualifications of the new editors as well as the combination of the individual
appointee's qualifications."
The four co-editors will be tasked
with maintaining the W3C's formal HTML5 specification, which seeks to be the
definitive document of the markup language that underlies the web.
It has also received funding from tech giants,
Microsoft, Google and Adobe. If you'd like to know more about the W3C's HTML5
Plan 2014, you can visit http://dev.w3.org/html5/decision-policy/html5-2014-plan.html
As always, we'd love to know what's
on your mind. Do you think HTML5 will hit the mark?
"My hope is that the net effect
of all this will be that work on the HTML Living Standard will accelerate
again, resuming the pace it had before we started working with the W3C working
group," Hickson wrote.
Critics of WHATWG's approach say the
whole idea of a living standard is silly, and that it will be impossible for
browsers to maintain compatibility with the HTML standard if the specifications
are in constant flux.
Overall, however, browser makers
appear to disagree. WHATWG was founded by representatives of Apple, Mozilla,
and Opera, and its current steering committee includes reps from Google. All of
those companies' browsers have already implemented HTML5 features, even though
the standard is not yet final.
But the consensus is not total.
Although Internet Explorer has also implemented HTML5 features, Microsoft has
yet to join WHATWG. Also, half of the new W3C HTML5 edit team hails from
Redmond.
The W3C gave no word on whether it
expects four editors to get the job of drafting the HTML5 spec done any faster
than one would have. At its present rate, the standards org says not to expect
HTML5 to reach "Recommendation" status – the final phase of the
standardization process – until 2014
Revised
HTML 5.0 milestones
The following are revised milestones based on the above plan:CR: 2012 Q4LCf: 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
- 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
