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

Hi henri,

>The HTML WG will focus on getting releases branches
>to REC and won’t position itself as a venue for developing new
>features.

I do not agree that the HTML WG should not be a venue for developing new
features.

regards
SteveF



On 15 October 2012 13:35, Henri Sivonen <hsivonen@iki.fi> wrote:

> On Fri, Oct 12, 2012 at 2:22 PM, 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
> >
> > 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.
>
> Or a tombstone Note if implementations aren’t forthcoming?
>
> >> “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.
>
> Since this working group is changing HTML5 from a catch-all thing to a
> snapshot set of Recommendations, I think it doesn't make sense to
> promote things that are not part of that set of Recommendations as
> being part of HTML5. Therefore, I propose that the group not engage in
> promoting things as being part of HTML5.
>
> If there is to be promotion (which I don't see as a core activity for
> a Working Group), I think it would make more sense to promote things
> as being part of the Web Platform. (I observe that the W3C has finally
> embraced this name when launching webplatform.org.) I propose using
> the following heuristic for determining if a feature is part of the
> Web Platform:
>
> Give the feature a score from 0 to 4 by giving 1 point for
> implementation in IE, 1 point for implementation in Firefox, 1 point
> for implementation in Opera and 1 point if for implementation either
> of or both of Chrome and Safari. (That is, if a feature is in both
> Chrome and Safari, it still counts only as 1 point.)
>
> Interpret the score as follows:
> 4: Definitely part of the platform
> 3: Part of the platform
> 2: On the fringe of the platform.
> 1: Not part of the platform
> 0: Definitely not part of the platform
>
> I'd be okay with the W3C promoting features that score 3 or 4 as being
> part of the Web Platform. (2 isn’t enough. For example SVG fonts and
> Web SQL Database would score 2.)
>
> FWIW, three years ago, this scoring was used on the level of TR page
> items by various people on the #whatwg IRC channel to see how well the
> W3C’s speccing activities focused on the Web Platform:
>
> https://docs.google.com/spreadsheet/ccc?key=0AtnDcoh7FXfAdEFuWVlVVDZTVkFWdnRqaWFGMzNYM3c#gid=0
>
> > 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.
>
> Do people who believe this fear that e.g. Selectors aren't widely
> implemented or will likely be dropped? Presumably not, so why not?
>
> > 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
>
> That comment displays extraordinary confusion, but it's confusion
> within the W3C. I don't think it's appropriate to engage in a
> promotion campaign to the general audience in order to address
> confusion within the W3C.
>
> If the scoring framework I proposed above is applied, the result is
> that XSLT 1.0 is definitely part of the platform but XSLT 2.0 is
> definitely not part of the platform. I expect the status of both XSLT
> 1.0 and XSLT 2.0 to be stable in that regard. (People who wish to run
> XSLT 2.0 on top of the Web Platform can obtain a product for doing so
> from Saxonica.)
>
> > Browser implementors are participating in responsive images.
>
> Not in the Community Group at the time srcset was proposed by hober.
>
> > Also, the WHATWG might not be the best counter example: not all
> > implementors are already participating productively and paying
> > attention to the WHATWG.
>
> Hopefully a CG FSA will address Microsoft’s past concerns about
> participating.
>
> > I'll also note that not everybody who participates in the WHATWG is
> > participating productively in the W3C HTML Working Group.
>
> I think this is a failure of the HTML WG to provide the sort of work
> environment that the WHATWG has succeeded in providing. I thank you
> for and welcome making civility enforcement part of the new Plan.
>
> > 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
>
> I am not authorized to read the page you refer to. Authorization
> Required for “HTML WG Chairs”.
>
> I’m making the assumption that you refer to the same quote seen in
>
> http://dev.w3.org/html5/decision-policy/html5-2014-plan.html#extension-specs
>
> I don't object to the two paragraphs quoted there. After all, it would
> be futile to object to them, since they merely describe how things
> work in practice. The same “applicable specifications” “extensibility
> mechanism” applies to all specifications—even those that vehemently
> deny extensibility.
>
> However, maintaining a list of specifications that *wish* to be
> recognized for the purpose of the sentence “When someone applying this
> specification to their activities decides that they will recognize the
> requirements of such an extension specification, it becomes an
> applicable specification.” doesn’t mean they *are* recognized by
> everyone.
>
> > You previously mentioned RDFa but did not chose to mention Microdata.
>
> I didn't wish to state an objection related to Microdata at this time.
>
> > 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.
>
> We have precedent for including legends about the lack of consensus in
> the Status of this Document section. The presently-current TR
> publication even lists individual open ISSUEs in its Status of this
> Document section: http://www.w3.org/TR/2012/WD-html5-20120329/
>
> As far as appearance of endorsement goes, I think publishing a draft
> for addressing an ISSUE should not appear to the general public as
> more endorsed by the participants of this WG than a draft published by
> a separate CG would. That is, I think there should be no promotional
> incentive to try to get an unbaked draft published via this WG instead
> of publishing it via a CG.
>
> >>> * 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’m merely asking that the output of the TF be presented on its own
> merit without implied endorsement of people who aren’t (for whatever
> reason) part of the TF. In other words, I’m just asking for truthful
> representation of provenance. Participants of this WG might be free to
> join the CSS WG in additition to this WG, but it would still be
> inappropriate to portray publications of the CSS WG as publications of
> this WG.
>
> >> 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
>
> I did read it carefully.
>
> > 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
>
> I'm not asking that spec text that this Working Group puts on the REC
> track come exclusively from the WHATWG; other Community Groups are
> potential sources, too (with the caveat I mentioned in my earlier
> email). My objection would be removed if the Plan had text to the
> effect of: “For the subsequent REC release branches (currently assumed
> to be called HTML 5.1, 5.2, etc.), the trunk from which the branches
> are cut will be the one maintained by the WHATWG for features (and
> updates thereof) that were in the March 29 2012 Working Draft of HTML5
> and still are in a draft maintained by the WHATWG at the time of
> cutting a branch. Patches to the trunk developed to implement Working
> Group Decisions (other than mere removal of features that didn’t meet
> CR exit criteria) may be carried forward to later release branches
> without revisiting the Decisions. Removals made due to failure to meet
> CR exit criteria shall be reassessed as those features may later meet
> CR exit criteria. For each new feature, the trunk from which the HTML
> WG cuts release branches may be maintained by the WHATWG or by another
> Community Group. The HTML WG will focus on getting releases branches
> to REC and won’t position itself as a venue for developing new
> features.”
>
> I find it concerning that the communications from the Chairs on the
> topic of the relationship between the HTML WG and the WHATWG have been
> consistently vaguer and less committal than communications coming from
> the CEO or the Communications Team. I’m also concerned about the
> prospect of developing new features in a venue that both has a bad
> track record at providing a good environment for such work and will be
> occupied with the opposite task of removing stuff in order to exit CR
> (i.e. this WG) while a venue with a good track record at providing an
> environment conducive of feature development (WHATWG) or not much of a
> track record—good or bad—(other CGs) are available. These concerns
> would be easy to address by being overt about the planned relationship
> by adopting text such as the text I proposed in the previous
> paragraph.
>
> --
> 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