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

hi Maciej,

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

I don't think an an 'extension' for HTML5 that is the removal of
hgroup really works ( I don't think that extensions that are meant to
replace  hgroup really work unless hgroup is also an extension, not
incumbent in the spec) extensions generally work for features not in
the spec., so I have created an alternate version of the spec with
hgroup removed:

HTML5 (- hgroup)
http://www.html5accessibility.com/HTML5extensions/HTML5.html


note: single page spec version has been known to crash browsers.

this is currently on my own server, can we please have a directory set
up on the w3c server to publish such specs , also please provide links
to such specs on the HTML WG homepage alongside the current drafts.

I will produce 2 more parallel specs 1 that has hgroup removed and
outlineMask 1 that has  hgroup removed and subline added



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 14:09:55 UTC