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

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 20 Sep 2012 15:06:38 -0700
Cc: Sam Ruby <rubys@intertwingly.net>, Jirka Kosek <jirka@kosek.cz>, 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: <6BA13046-74B2-49F1-8C58-AA8EB513F4B8@apple.com>
To: Steve Faulkner <faulkner.steve@gmail.com>

On Sep 20, 2012, at 1:39 PM, Steve Faulkner <faulkner.steve@gmail.com> wrote:

> Hi Sam,
> 
>> This may lead to an unusual place: a name that has parsing behavior but is not allowed to be used.  This may be unusual but not unprecedented.
> 
> Am I missing something here or are there not quite a few elements and
> attributes [1] that have parsing behaviour but are not allowed to be
> used?
> 
> [1] http://dev.w3.org/html5/spec/obsolete.html#non-conforming-features

It's indeed very precedented, at least in HTML5.

 - Maciej


> 
> regards
> SteveF
> 
> On 20 September 2012 21:33, Sam Ruby <rubys@intertwingly.net> wrote:
>> On 09/20/2012 12:33 PM, Steve Faulkner wrote:
>>> 
>>> hi Maciej,
>>> 
>>>> For reference, the HTML5 spec explicitly allows extensions to render
>>>> specific elements nonconforming (emphasis added):
>>> 
>>> 
>>> what i meant was not about whether it was technically doable in HTML5,
>>> but whether it was practically meaningful. if the default for HTMl5
>>> validation is that <hgroup> is conforming.
>> 
>> 
>> Thanks for identifying with precision what the issue is.
>> 
>> We may have different perspectives, but the operational outcome may be
>> closer than we expect.
>> 
>> Plan2014 suggests that we start with the current specification and begin a
>> process to identify what features are at risk and to drop those should they
>> not make the exit criteria.  It only sketched this in high level outline
>> form (syntax vs semantics).
>> 
>> Maciej suggested that the outline algorithm was likely at risk.  Steve
>> identified other aspects, and has now identified conformance criteria.
>> 
>> Steve has now produced a document with all traces of hgroup removed.
>> 
>> To date I have been thinking in terms of a black list (what features need to
>> be removed).  If -- as a thought experiment -- we started with Steve's
>> document and asked what features are already or are likely to be
>> implemented, and therefore should be added... where would we end up?
>> 
>> Maciej has already identified parser behavior as one such item (specifically
>> HTMLElement interface, rather than HTMLUnknownElement). Are there others?
>> 
>> Specifically, does it make sense to consider hgroup conforming if we were to
>> determine that the semantics behind it is not?
>> 
>> This may lead to an unusual place: a name that has parsing behavior but is
>> not allowed to be used.  This may be unusual but not unprecedented. If you
>> look at JavaScript, there are such words that were intended to be a part of
>> future specifications but never were:
>> 
>> https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Reserved_Words
>> 
>> True the error recovery actions are different (in JavaScript you can get a
>> static compilation error, in HTML5 the parser recovers), but these actions
>> are consistent with the underlying philosophy of the respective languages.
>> 
>> I'm not going to put forward a suggestion as to what should be on the white
>> or black lists -- I'm just putting this forward in the hopes that we can
>> come to agreement on the operational details of the plan even if we cannot
>> come to agreement on the rationale behind that plan.
>> 
>>> regards
>>> SteveF
>> 
>> 
>> - Sam Ruby
>> 
>> 
>>> On 20 September 2012 18:17, Maciej Stachowiak <mjs@apple.com> wrote:
>>>> 
>>>> 
>>>> On Sep 20, 2012, at 7:08 AM, Steve Faulkner <faulkner.steve@gmail.com>
>>>> wrote:
>>>> 
>>>>> 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.,
>>>> 
>>>> 
>>>> For reference, the HTML5 spec explicitly allows extensions to render
>>>> specific elements nonconforming (emphasis added):
>>>> 
>>>> "When vendor-neutral extensions to this specification are needed, either
>>>> this specification can be updated accordingly, or an extension specification
>>>> can be written that overrides the requirements in this specification. When
>>>> someone applying this specification to their activities decides that they
>>>> will recognize the requirements of such an extension specification, it
>>>> becomes an applicable specification.
>>>> 
>>>> The conformance terminology for documents depends on the nature of the
>>>> changes introduced by such applicable specificactions, and on the content
>>>> and intended interpretation of the document. Applicable specifications MAY
>>>> define new document content (e.g. a foobar element), **MAY prohibit certain
>>>> otherwise conforming content** (e.g. prohibit use of <table>s), or MAY
>>>> change the semantics, DOM mappings, or other processing rules for content
>>>> defined in this specification. "
>>>> 
>>>> <http://dev.w3.org/html5/spec/single-page.html#extensibility>
>>>> 
>>>> So while it might sound odd, it does "work" and is explicitly allowed by
>>>> 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
>>>> 
>>>> 
>>>> That approach is certainly permitted, but I suspect it will be harder to
>>>> get consensus for FPWD of a modified parallel spec than of an extension
>>>> spec, based on past experience.
>>>> 
>>>> 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 22:07:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 20 September 2012 22:07:12 GMT