- From: Steve Faulkner <faulkner.steve@gmail.com>
- Date: Thu, 20 Sep 2012 13:17:24 +0200
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Jirka Kosek <jirka@kosek.cz>, Sam Ruby <rubys@intertwingly.net>, Paul Cotton <Paul.Cotton@microsoft.com>, "public-html@w3.org" <public-html@w3.org>, "w3c-wai-pf@w3.org" <w3c-wai-pf@w3.org>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>, "Janina Sajka <janina@rednote.net> (janina@rednote.net)" <janina@rednote.net>, Philippe Le Hegaret <plh@w3.org>, "Judy Brewer <jbrewer@w3.org> (jbrewer@w3.org)" <jbrewer@w3.org>, Jeff Jaffe <jeff@w3.org>, Tim Berners-Lee <timbl@w3.org>
Hi maciej, > (2) I don't believe there is any implementation of the outline algorithm, which is where the semantics of hgroup matter. In my personal opinion, the outline >algorithm as a whole should be marked "at-risk" at the very least. hgroup (if implemented) as currently deifined effects (negatively I think) the semantics exposed to AT independent of the the outline algorithm, so outline is not the only situation that hgroup semantics matter. regards SteveF On 20 September 2012 02:44, Maciej Stachowiak <mjs@apple.com> wrote: > > Hi Jirka, > > On Sep 19, 2012, at 3:24 PM, Jirka Kosek <jirka@kosek.cz> wrote: > >> On 20.9.2012 0:02, Sam Ruby wrote: >> >>>>> 164 hgroup element >>>>> >>>>> Retain the current hgroup language in the spec. Note that a number of >>>>> shipping browsers implement the syntax. Identify the semantics as an >>>>> at risk feature. >>> >>> Why did you stop reading there? The very next paragraph suggests the >>> possibility that extension specs (plural) be written. >> >> Of course, I read the whole document. You are probably refering to part: >> "... MAY prohibit certain otherwise conforming content (e.g. prohibit >> use of <hgroup>s)..." >> >> It just seems odd to keep controversial hgroup in spec and allow >> creation of extension spec which will prohibit it. It makes more sense >> to have extension spec which extends not shrinks something. >> >> If the plan is to get to REC status faster then all features which are >> controversial or not yet interoperable should be moved to extension >> specs. If for some features you propose to split them (some a11y ones) >> and for some to keep them (eg. hgroup) then the plan doesn't look as >> very unbiased. > > Our going in assumption was to propose no immediate changes to the HTML5 spec for any of the current open issues, for consistency. If extension specs appear for some of the hgroup alternatives, then I think it would be reasonable to suggest to the WG to move hgroup itself to an extension. But as Sam said, it seems premature to suggest that before other extension specs exist. It is also possible that hgroup will fail to meet CR exit criteria and therefore get dropped even without alternatives. That too is a call we have to make. > > A few technical points: > > (1) <hgroup> parsing is *not* identical to a random unknown element; it is observable whether a browser recognizes it or not. For example, when instantiated it will be the HTMLElement interface, rather than HTMLUnknownElement. > > (2) I don't believe there is any implementation of the outline algorithm, which is where the semantics of hgroup matter. In my personal opinion, the outline algorithm as a whole should be marked "at-risk" at the very least. > > Regards, > Maciej > > -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Received on Thursday, 20 September 2012 11:18:39 UTC