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

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

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 20:40:51 UTC