HTML5 spec. seems to unnecessarily ban strict mode event handlers
allen at wirfs-brock.com
Thu Mar 17 14:17:14 PDT 2011
The issue has been address in the HTML spec as http://www.w3.org/Bugs/Public/show_bug.cgi?id=11977
On Mar 17, 2011, at 12:33 PM, Juriy Zaytsev wrote:
> Thanks for bringing this quirk to the surface. I remember being puzzled by the presence of this wording in HTML5 spec but never got a chance to do anything about it.
> By "non-standard" I meant "not part of ECMA-262 standard" (not that it's not part of any other standard, such as HTML5... which — to be precise — is not yet a standard, as far as I understand). I changed the wording of the test to make it clearer — http://kangax.github.com/es5-compat-table/strict-mode/
> And while we're on this subject, I've been tinkering with compat. table of non-standard ES features across various (modern and not so modern) implementations — http://kangax.github.com/es5-compat-table/non-standard/
> Might be useful in assessing the risk of dropping/introducing certain extensions in future versions of ES.
> On Thu, Feb 3, 2011 at 5:00 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> I was browsing Kangax's strict mode test result page (http://kangax.github.com/es5-compat-table/strict-mode/ ) and I noticed that he listed the recognition of a use strict directive of a event handler as a "non-standard" feature that he tests for. This spiked my curiosity as my recollection was the HTML5 event handler content attribute was specified to be text that is an ECMAScript FunctionBody. FunctionBody may contain a Directive Prologue that includes a use strict directive so, from an ECMAScript perspective, there shouldn't be anything non-standard about a strict mode event handler.
> To be sure, I checked the event handler section of the HTML5 spec (http://dev.w3.org/html5/spec/Overview.html#event-handler-attributes) and to my surprise I discovered that it specifies the creation of the handler function in a manner that, at first glance, seems to explicitly cause the presence of a use strict directive to be ignored. Essentially it seems to specify that event handlers specified using the event handler attribute are never executed in ECMAScript 5 strict mode. I don't know whether or not this was intentional, but it certainly seems wrong. The "strictness" of an ECMAScript function is an internal and local characteristic of the function. For a ECMAScript host to say that a use strict directive is ignored is really no different from saying that IfStatements or any other syntactically valid element of a FunctionBody will be ignored.
> The HTML5 spec. get into this trouble because of the way it uses the abstract operation for creating function objects defined by section 13.2 of the ES5 specification (http://www.ecma-international.org/publications/standards/Ecma-262.htm). In step 2 of the algorithm in HTML5 22.214.171.124 it unconditionally uses False as the Strict parameter to the ES5 13.2 algorithm. That might seem to exclude the function from strict mode, however that isn't actually the case. All the Strict parameter to 13.2 controls is whether or not "poison-pill" properties for 'caller' and 'arguments' are created for the function object. The semantics of strict mode are specified throughout the ES5 specification and are control by the actual lexical occurrence of a use strict directive. The Strict parameter to 13.2 does not alter this semantics.
> The HTML5 spec. also contains another related bug. Step three says "If the previous steps failed to compile the script, then ..." where the "previous steps" pretty clearly references the use of ES5 13.2 in the immediately preceding step 2. However, there is nothing in ES5 13.2 that concerns the compilation of ECMAScript source text. Instead 13.2 expects to be passed an valid FunctionBody. That validation ("compilation") must occur somewhere else.
> It appears to me that these problem are probably the result of the HTML5 algorithm being patterned after the wrong parts of the ES5 spec. The appropriate part of the ES5 spec. to use as a model is steps 8-11 of ES5 126.96.36.199. This is the definition of the Function constructor. These steps correctly take care of parsing the FunctionBody and handling any resulting syntax errors. It also calls 13.2 with a correct Strict parameter. Replacing HTML5 188.8.131.52 steps 2-3 with steps modeled after ES5 184.108.40.206 steps, 8, 9, and 11 (step 10 is not applicable) should correct these issues.
> Finally, Kangax also lists as a "non-standard" feature the recognition of strict coder as the string argument to setTimeout. I couldn't find anything the HTML5 spec. that could be interpreted as excluding strict ECMAScript code in this context.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss