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. -- kangax On Thu, Feb 3, 2011 at 5:00 PM, Allen Wirfs-Brock <[email protected]>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. > > Allen
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
