- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Mon, 15 Oct 2012 16:22:34 +0300
- To: public-html WG <public-html@w3.org>
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