- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Mon, 15 Oct 2012 15:35:08 +0300
- To: public-html WG <public-html@w3.org>
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