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

Re: Extension spec for hgroup (Was: Re: Getting HTML5 to Recommendation in 2014)

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 19 Sep 2012 17:44:35 -0700
Cc: 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>
Message-id: <28440182-CF2E-4F08-93D3-C75A7EECE4F3@apple.com>
To: Jirka Kosek <jirka@kosek.cz>

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.

Received on Thursday, 20 September 2012 00:45:07 UTC

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