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

On Fri, Oct 12, 2012 at 4:45 PM, Steve Faulkner
<faulkner.steve@gmail.com> wrote:
> What does "broader buy-in, including from implementors, showing that the
> extension specification is seen as a good idea." mean in practice?

In practice, it would mean two implementors working on two distinct
browser engines saying that the proposed feature is a good idea that
they would like to implement and realistically might. (No
authoritative commitment to implement or a statement about timeline
required.) Ideally, it would also mean an indication of support and
likelihood of adoption from Web authors, but, as far as I can tell,
the W3C or its participants have not yet figured out how to
meaningfully gauge if Web authors would actually like to use a feature
if the feature existed. (You can probably always find a couple of Web
authors who say they like a given feature, but that doesn't really
tell you anything about what kind of author adoption a feature would
really get on the Web scale.)

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

I was talking about the standard of inclusion for new features. At
this point, hgroup in the parser or UA stylesheet is not a prospective
new idea but an interoperably implemented piece of the Web Platform.

If you combine my position on hgroup in the parser and UA stylesheet
and your outlook for it affecting the outline exposed for
accessibility, it would not be unreasonable to conclude that the
standard of inclusion at the WHATWG has been too lax in the case of
hgroup. However, there is no logical contradiction between my position
on keeping hgroup in the parser and the UA stylesheet and at the same
time calling for a stricter standard of inclusion for future features.

As for support in the various communities, I think it's semi-relevant
to mention that what constitutes a valid an EPUB3 Navigation Document
involves a normative statement about hgroup. This is not necessarily
an endorsement of hgroup by the IDPF, since the normative statement is
likely simply a result of working with what I draft of HTML5 provided.
Also, I don't think the evolution of the Web Platform should be
constrained by non-Web reuses of Web technology. My point is that at
this point, there exists at least one external community that has
already built upon the assumption that hgroup exists. (Their building
upon it seems to be restricted to document conformance, though. I see
no requirements on Reading Systems hinging on hgroup processing.)

For Web authors to make pages for which the outline algorithm provides
sensible outlines, I think it needs to have a tangible visual effect
in Web authoring. I think in practice, that would mean having a
selector that matches on the outline depth. I think implementing such
a selector in a performant way would be the real test of
implementability and merit for the outline algorithm in general and
the role of hgroup in it in particular.

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

Another implementor expressing an opinion that it is a good idea and
interest in implementing the accessibility mapping in a non-Gecko
engine.

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

Received on Monday, 15 October 2012 13:23:06 UTC