HTML5 spec. seems to unnecessarily ban strict mode event handlers
kangax at gmail.com
Thu Mar 17 12:33:20 PDT 2011
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 (
> In step 2 of the algorithm in HTML5 126.96.36.199 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
> 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
> 188.8.131.52. 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 184.108.40.206 steps 2-3 with steps modeled after ES5 220.127.116.11
> 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