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

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

Received on Thursday, 20 September 2012 19:34:06 UTC