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

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/

Received on Thursday, 11 October 2012 16:03:13 UTC