- From: Sam Ruby <rubys@intertwingly.net>
- Date: Fri, 12 Oct 2012 07:22:16 -0400
- To: public-html@w3.org
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