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

On Fri, Oct 12, 2012 at 11:46 AM, Steve Faulkner
<faulkner.steve@gmail.com> wrote:
>> 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.

I think a standard of inclusion that would include stuff unless it has
explicit opposition to the point of refusal to implement would not
represent appropriate stewardship of the Web Platform. To keep the
quality of the platform high, “not super-bad” is not high enough
standard of inclusion. See also
http://wiki.whatwg.org/wiki/FAQ#Where.27s_the_harm_in_adding.E2.80.94

> * 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 don't meet to even the "random employee" level of authority, since
I am not an employee of an implementor organization.)

Stipulating the sort of thing you stipulate is a way to tilt the odds
heavily in the direction of not getting opposition that meets your
criteria for acceptable opposition. Implementor organizations may not
have processes for coming up with authoritative positions. Or the
processes might be so heavy that it would be unreasonable to allow
virtually any working group participant to trigger such a process. Or
implementor organizations may have policies against making
authoritative forward-looking statements about products. Moreover,
even when it might be possible for an organization to come up with an
authoritative affirmation of support, the bar for authoritative
negatives is likely much higher.

Furthermore, presenting being "partisan" as something that might
disqualify a claim is a way to potentially disqualify any opinion that
disagrees with yours. After all, it's hard to prove that one's opinion
arises from independent thought and not from affiliation (alleged or
actual) with a party.

A standard of inclusion that requires an authoritative non-partisan
statement of intention not to implement in order to fail the standard
of inclusion would in practice be an "anything goes" standard of
inclusion.

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

Well, you put forward a draft that removed sensitivity to hgroup
tokens from the parsing algorithm and removed hgroup { display: block;
} from the UA stylesheet. Thank you for fixing the parsing part of
your proposal when notified, but I now noticed that I failed to notice
your removal of the bit of UA stylesheet, too.

I'm *very* unamused about offering the opportunity for this kind of
removals that require vigilance on the part of other participants to
maintain stuff that has been interoperable implemented and that we
shouldn't, in my opinion, have to spend any time or attention on.

I made clear what I agree with and what I object to in the CfC bullet
point about hgroup, since the bullet point is general enough that if
the CfC passed as-is, the group might have inadvertently opened the
door for moving away from interoperability.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Friday, 12 October 2012 10:18:01 UTC