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

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/

Received on Monday, 15 October 2012 12:35:43 UTC