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

Hi Sam

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 would note that interoperable implementation of the (parsing/display)
aspects of a feature is a good reason for keeping a feature specified in
the parsing algorithm or UA stylesheet. It is not a good reason for keeping
a feature as conforming (i.e. not obsoleting it).


regards
SteveF




On 12 October 2012 12:22, Sam Ruby <rubys@intertwingly.net> wrote:

> 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<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<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<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<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<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<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=15213>
> https://www.w3.org/Bugs/**Public/show_bug.cgi?id=18384<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<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<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<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<http://lists.w3.org/Archives/Public/www-archive/2012Oct/0012.html>
>
> - Sam Ruby
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html