On 02/03/2011 05:00 PM, Allen Wirfs-Brock 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 6.1.6.1 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 15.3.2.1. 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 6.1.6.1 steps
2-3 with steps modeled after ES5 15.3.2.1 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.
Any chance you could open one or more bugs on this?
http://w3.org/brief/MjA2
Doing it via the bugzilla interface gives you an increased ability to be
notified and participate, but you can also use the form directly on the
W3C spec itself:
http://dev.w3.org/html5/spec/#status-of-this-document
Or the form at the bottom of every page on the WHATWG spec:
http://www.whatwg.org/specs/web-apps/current-work/multipage/
Whichever way you enter it, it ends up in the same place.
- Sam Ruby
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
