- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 20 Sep 2012 15:06:38 -0700
- To: Steve Faulkner <faulkner.steve@gmail.com>
- 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>
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 UTC