Re: [HTMLWG] CfC: Adopt "Plan 2014" and make some specific related decisions

On 10/11/2012 12:02 PM, Henri Sivonen wrote:
>
> I object to taking an Extension Specification to FPWD simply when a WG
> participant offers a draft.

We have never done that.  We have always done a call for consensus prior 
to publishing.  Before the next FPWD, we probably should address the 
following bug:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=8895

I'll also note that the goal is not to stay in Working Draft state 
indefinitely, as it unfortunately may have appeared was the case with 
the W3C HTML5 specification.  The plan is to instead begin to focus on 
exit criteria based on actual implementation experience and start moving 
things to Recommendation status.

> “In addition, we will work to find ways to promote these extensions as
> a part of a family of HTML5 specifications.”
>
> What criteria must an extension to fulfill to get promotion under the
> HTML5 brand? I object to promoting Web Intents, HTML+RDFa or Encrypted
> Media Extensions like that.

Concrete proposals welcome.  The intent here is to correct the 
widespread misperception that unless something is specified in the 
kitchen sink spec it isn't widely implemented or will likely be dropped. 
  The plan cites plenty of counter examples to this, and yet that 
perception persists:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=14689#c18

> I think that it's risky to establish a new venue for each such
> specification. Experience suggests that developing specifications for
> the Web Platform without the participation of browser implementors
> leads to technically bad results and to frustration. Therefore, I
> advise against establishing a new Community Group for each feature
> like happened recently with responsive images. It's better to propose
> and develop new features where implementors are already participating
> productively and paying attention, such as the WHATWG or the WebApps
> WG.

Browser implementors are participating in responsive images.

Also, the WHATWG might not be the best counter example: not all 
implementors are already participating productively and paying attention 
to the WHATWG.

I'll also note that not everybody who participates in the WHATWG is 
participating productively in the W3C HTML Working Group.

This indeed is a hard problem.

> Conceptually, *giving* someone with the authority to create willful
> violations doesn't make sense. One is supposed to *take* that
> authority when the entity who specs are being willfully violated isn't
> doing its job properly.

Do you object to the paragraphs in section 2.2.3 of the HTML 
specification which are quoted here?

http://intertwingly.net/tmp/wgchair/plan2014#extension-specs

We have had a very real problem that not all browser vendors were 
participating fully in the a11y task force.  We have had a very real 
problem where people were objecting without proposing something 
concrete.  Plan 2014 focuses on getting people to write concrete 
proposals and to measure those proposals based on implementation experience.

>> * Make a WG Decision to adopt Version 3 of the HTML Working Group Decision Policy: <http://dev.w3.org/html5/decision-policy/decision-policy-v3.html>
>>      (A summary of the changes is available here: <http://dev.w3.org/html5/decision-policy/html5-2014-plan.html#dp> and here <http://lists.w3.org/Archives/Public/public-html/2012Aug/0188.html>)
>
> The Plan talks about writing Extension Specifications instead of
> ISSUEs. Yet, version 3 of the Decision Policy still talks about Change
> Proposals rather than Extension Specifications. Are dissenters
> supposed to write Extension Specifications or Change Proposals? Or
> does writing Extension Specifications only apply to pre-existing
> ISSUEs?

The plan is to begin to lock down HTML 5.0 and to actively begin work on 
HTML 5.1.  Shortly after we establish a new plan, we will need to 
evaluate specific TrackerRequests:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15213
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18384

Should some form of the plan pass, I would expect that the only issues 
we would accept to be addressed in the 5.0 time frame would be ones that 
address known interoperability issues, and that we would encourage new 
features to be addressed, at least initially, via extension specifications.

>> * Make WG Decisions to pursue each of HTML Working Group issues 30, 164, 185, 194, 195, 200, 203, and 206 as extension specifications
>
> See above. I think it’s a good idea to keep these separate unless they
> meet the CR exit criteria, but I think they should be even more
> separate: not positioned as publications of this WG. At the very
> least, the Status of this Document section should identify these as
> dissenting opinions and not as specifications on par with the Working
> Group deliverables that enjoy more consensus. I object to deciding to
> publish such Extension Specifications in a way that portrays them as
> being on equal footing with for example the canvas API and fails to
> conspicuously portray them as dissenting opinions.

You previously mentioned RDFa but did not chose to mention Microdata. 
The fact remains that there are dissenting opinions on both, and yet 
there is widespread implementation of each.

In any case, decisions to publish will be made on a case by case basis, 
generally by a call for consensus, sometimes by surveys.  We will 
encourage people to participate in these discussions.  I personally 
would support having information in the status section of documents 
which reflects the real world deployment (ideally both in terms of 
author usage and implementation status).  I however would be skeptical 
of proposals to include conspicuous inclusion of vague or philosophical 
concerns.

>> * Make a WG Decision to amend to the HTML  Accessibility Task Force Work Statement to allow the Task Force to create extension specs for accessibility-related issues, as follows: <http://lists.w3.org/Archives/Public/public-html/2012Oct/0016.html>
>>     NOTE: to take effect, this amendment must also be approved by the Protocols & Formats Working Group, and the Task Force itself.
>
> I object to this if the resulting Extension Specifications are
> portrayed as deliverables of the HTML WG. At the very least, the
> Status of this Document section should make it clear that only a
> subset of the Working Group has had authority over the contents of the
> specification and such specification should not receive brand
> promotion according to the promotion provision of the Plan.

There is no subsetting: every member of the HTML WG who is interested in 
one of these topics is not only welcome but encouraged to participate in 
the A11y Task Force.  I will also note that such documents will require 
approval of the overall WG.

I will, however, note that the intent is truly to get all of the people 
interested in a topic together.  If there are objections to a proposal 
which is being developed in the Task Force, such will be forwarded to 
the Task Force and those that wish to participate in the resolution of 
the issue should participate there.

> I object to treating the inclusion of the hgroup name in the parsing
> algorithm as being at risk, since it has been interoperable
> implemented in all the major browser engines. I also object to
> treating the UA stylesheet rule hgroup { display: block; } as being at
> risk, because it, too, has been interoperable implemented in all the
> major browser engines.

Good input.

> I object to the plan of being silent on what the master branch is. I
> think the master branch should be the one maintained by the WHATWG. I
> expect this to be congruent with what the CEO of the W3C expressed in
> http://www.w3.org/QA/2012/07/html5_and_htmlnext.html about Ian working
> on .next.

I encourage you to read carefully the proposed charter changes mentioned 
here:

http://dev.w3.org/html5/decision-policy/html5-2014-plan.html#other-changes

We have discussed this Face to Face with the CEO and Director.  The 
WHATWG will indeed be a source of .next proposals, but will not be an 
exclusive source.  We have a number of bugs that have been fixed in the 
W3C HTML 5 specification that have not been addressed in the WHATWG 
specification.  There also are a few areas where the specifications are 
intentionally different, and appear to be destined to remain that way. 
For example:

http://lists.w3.org/Archives/Public/www-archive/2012Oct/0012.html

- Sam Ruby

Received on Friday, 12 October 2012 11:22:53 UTC