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

hi henri,

I think to go to FPWD,  there should be broader buy-in, including from
> implementors, showing
> that the extension specification is seen as a good idea.
>

I think that if implementors* speak up and say we will NOT implement the
proposed feature and provide a detailed technical explanation of why, or we
would implement the feature, but think the specification should be modified
in x ways, it is reasonable that the proposed feature not become an FPWD at
that point.

* by implementors I would expect the person making the claim to be making
it with some authority, not just a random employee who may or may not be
partisan.


>I object to treating the inclusion of the hgroup name in the parsing
algorithm as being at risk

I don't think anybody has proposed this, have they?
I have proposed extension spec text, in which for authoring conformance
hgroup be made obsolete (like <center> etc),because its sole stated reason
for being in the spec in the first place is to mask subheadings from the
outline algorithm (with a knock on effect of collapsing heading semantics
in accessibility APIs) and the outline algorithm has not been implemented
(except in a borked way by the JAWS screen reader, which also does not
implement hgroups effect on the outline).


regards
Steve

On 11 October 2012 17:02, Henri Sivonen <hsivonen@iki.fi> wrote:

> On Tue, Oct 9, 2012 at 12:02 AM, Maciej Stachowiak <mjs@apple.com> wrote:
> > If the HTML Working Group passes this Call for Consensus, then the
> Working Group shall:
> > * Endorse sending the plan as a whole as input to the W3C to guide
> revisions to the HTML Working Group charter: <
> http://dev.w3.org/html5/decision-policy/html5-2014-plan.html>
>
> “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.”
>
> Requiring ISSUE-driven changes to meet the criteria for CR exit is a
> good idea for protecting the core deliverables from changes that
> aren't backed by broader buy-in. However, publishing the extension
> specifications as deliverables of the HTML WG poses a risk.
>
> I object to taking an Extension Specification to FPWD simply when a WG
> participant offers a draft. (The plan is not clear about FPWD
> criteria, but the sentiment as well as past Chair actions and a later
> bullet point in your email suggest a very low bar for FPWD, so I’m
> objecting to something that only seems to be part of the plan as I
> don’t have any concrete text to object to.) I think to go to FPWD,
> there should be broader buy-in, including from implementors, showing
> that the extension specification is seen as a good idea.
>
> One of our grievances with the WHATWG has been that Hixie has
> sometimes put unbaked stuff in the monolithic spec giving unbaked
> stuff undue weight to make it appear to be on par with the well-baked
> stuff or, worse, has kept stuff that has received explicitly negative
> implementor feedback and no positive enthusiasm in the spec (consider
> context menu items). Keeping stuff like that in the spec is basically
> a bait for the more indifferent implementors to implement the unbaked
> or bad feature.
>
> Letting any HTML WG participant write up an Extension Specification
> and get it published as an FPWD does not address our grievance with
> Hixie and the WHATWG. Instead, it potentially multiplies the problem.
> We shouldn't evolve the Web platform by leaving bad features as bait
> out there for long enough to someone who hasn't been paying attention
> to implement (e.g. to score on “HTML5” testing sites). Instead, I
> think we should require affirmative indication that a couple of
> implementors think a feature is a good idea before publishing it in a
> way that makes the feature seem like a peer to the features that are
> already widely deployed or otherwise are widely agreed to.
>
> “To prevent unnecessary confusion, the HTML5 specification will drop
> explicit indications that any given extension is obsolete once an
> extension specification exists that has been published as a FPWD.”
>
> It seems to me that this isn't for preventing confusion but for
> preventing political ratholing about the indications. I expect
> mutually contradictory Extension Specifications published by the HTML
> WG to *increase* confusion.
>
> “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. In general, I think the specs should carry
> their own weight instead of relying on being perceived to be part of
> HTML5. For example, Anne’s Encoding Standard shows that if a spec has
> merit on its own, it will get respect without such brand promotion.
>
> “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.”
>
> The strategy of splitting things up so that controversial stuff gets
> to proceed in peace makes me even more concerned about the
> above-mentioned problem of giving undue weight to ideas that someone
> who’d have raised an ISSUE under the old process has written up
> without affirmative implementor buy-in that it is a good idea.
>
> “The 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”
>
> This is good even though very vague.
>
> “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.”
>
> 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.
>
> “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.”
>
> It seems unfortunate to prioritize the ability of different parties to
> write down what they like over having a proper definition of what
> needs to be implemented. This sort of thing will lead to author
> confusion, since Web authors in general won't have a good idea of the
> W3C politics to figure out which conflicting document will be treated
> as the real thing for purposes of implementation i.e. what will
> actually work.
>
> 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.
>
> > * 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?
>
> > * 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.
>
> > * 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.
>
> > * Include hgroup in the list of at-risk features for HTML5.
>
> What exactly does this mean? I agree that the contribution of hgroup
> to the document outline should be considered to be at-risk unless two
> browsers implement the outline algorithm in an hgroup-sensitive way.
> In fact, I expect the entire outline algorithm to be at-risk.
>
> 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. I intend to Formally Object to any Working
> Group Decision that removes the hgroup-related interoperably
> implemented parts of the parsing algorithm or the UA stylesheet from a
> deliverable that describes the parsing algorithm or the UA stylesheet
> or to any Working Group Decision that decides to publish an Extension
> Specification that seeks to modify UA conformance criteria by the
> means of a delta spec to the effect of removing said parts.
>
> On Tue, Oct 9, 2012 at 1:23 AM, Sam Ruby <rubys@intertwingly.net> wrote:
> > generally, there is a
> > generic "master" branch on which work continues.  Periodically there is
> > a new branch created in which work is stabilized.
>
> 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.
>
> --
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/
>
>


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