- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Fri, 12 Oct 2012 13:17:32 +0300
- To: public-html WG <public-html@w3.org>
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