HTML5 spec. seems to unnecessarily ban strict mode event handlers

Juriy Zaytsev kangax at
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 —

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 —

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

> I was browsing Kangax's strict mode test result page (
> ) 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 (
> 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 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
>  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 steps 2-3 with steps modeled after ES5
> 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.
> Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list