W3C home > Mailing lists > Public > public-html@w3.org > October 2012

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

From: Steve Faulkner <faulkner.steve@gmail.com>
Date: Tue, 16 Oct 2012 00:02:34 +0200
Message-ID: <CA+ri+V=GXfBh91=VErBhz80by46hEDSXhkpFGQjOZn1Cyjbg+A@mail.gmail.com>
To: Henri Sivonen <hsivonen@iki.fi>
Cc: public-html WG <public-html@w3.org>
Hi Henri,

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.

Ok so have talked to the main chrome accessibility engineer, and he
indicated that he would implement it if it had support from the community.


On 15 October 2012 15:22, Henri Sivonen <hsivonen@iki.fi> wrote:

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

with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
HTML5: Techniques for providing useful text alternatives -
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Received on Monday, 15 October 2012 22:03:43 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:28 UTC