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

Hi Henri,

What does "broader buy-in, including from implementors, showing that the
extension specification is seen as a good idea." mean in practice?

What we know from the hgroup feature is that it does not have buy-in from
vendors for the implementation aspects that have any real effect (outline
and accessibility API mapping). We know that it does no have wide support
from the various communities. we know various proposals for
removal/replacement were submitted form varying sources. i.e its not seen
as being a good idea and that has been the case for an extended period of
time.


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.


This was not my intent, my intent was to suggest what your statement
"broader buy-in, including from implementors, showing that the extension
specification is seen as a good idea." could mean in practice. As its
difficult to get  implementors to say they will implement a feature or
aspects of a feature (for example when i asked about title attribute got a
pretty much standard "we don't say" response) asking implementors to
indicate that they will not implement seemed a sensible way of stopping
progression of specs that are not practical.


Taking another example, the <maincontent> element [3] this is an extension
specification that I will be putting forward as a FPWD, it builds on common
authoring practices it provides built in rather than bolt on accessibility,
it has support from the developer and accessibility community, in
discussions I have had with accessibility engineers from mozilla they
indicated that they would implement the accessibility mapping, it is
publically available for wider review, no implementors have objected to it
(yet), what more do I need to do for it be considered as reasonable for
publishing as a FPWD?


Well, you put forward a draft that removed sensitivity to hgroup


It was a draft aimed at understanding what needed to be removed (and what
didn't) from the spec if hgroup was declared obsolete, its not a draft that
I would expect to get published as a FPWD as its a copy of the complete
HTML5 spec (- hgroup)  the 2 extension specs [1] relating to hgroup that I
have been working both propose that hgroup join the ranks of other features
obsoleted in HTML5 [1]


regards
SteveF

[1]
http://www.html5accessibility.com/HTML5extensions/outlineMask.html
http://www.html5accessibility.com/HTML5extensions/subline.html

[2] http://dev.w3.org/html5/spec/obsolete.html#non-conforming-features

[3]
https://dvcs.w3.org/hg/html-extensions/raw-file/0d72e410cd82/maincontent/index.html

On 12 October 2012 11:17, Henri Sivonen <hsivonen@iki.fi> wrote:

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