W3C home > Mailing lists > Public > public-html@w3.org > February 2011

[Bug 11977] New: HTML5 spec. seems to unnecessarily ban strict mode event handlers

From: <bugzilla@jessica.w3.org>
Date: Thu, 03 Feb 2011 23:14:53 +0000
To: public-html@w3.org
Message-ID: <bug-11977-2495@http.www.w3.org/Bugs/Public/>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11977

           Summary: HTML5 spec. seems to unnecessarily ban strict mode
                    event handlers
           Product: HTML WG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: allen@wirfs-brock.com
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


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.

Here is better language to use in 6.1.6.1:

replace existing steps 2-3 with:
----------------------
2. Let body be the event handler content attribute's new value.
3. If body cannot be parsed as an ECMAScript FunctionBody as specified in
[ECMA262] clause 13, then set the corresponding event handler to null and abort
these steps.
4.

Using this script execution environment from step 1, create a function object
(as defined in ECMAScript edition 5 section 13.2 Creating Function Objects),
with:

Parameter list FormalParameterList

    If the attribute is the onerror attribute of the Window object
        Let the function have three arguments, named event, source, and fileno.
    Otherwise
        Let the function have a single argument called event. 

Function body FunctionBody
    The event handler content attribute's new value.
Lexical Environment Scope

        Let Scope be the result of NewObjectEnvironment(the element's Document,
the global environment).
        If the element has a form owner, let Scope be the result of
NewObjectEnvironment(the element's form owner, Scope).
        Let Scope be the result of NewObjectEnvironment(the element's object,
Scope).

    NewObjectEnvironment() is defined in ECMAScript edition 5 section 10.2.2.3
NewObjectEnvironment (O, E). [ECMA262]
Boolean flag Strict
    If body is strict mode code let Strict be true, otherwise let Strict be
false.

Let this new function be the only entry in the script's list of code
entry-points.
---------------------
Renumber existing steps 4&5 as 5&6

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Thursday, 3 February 2011 23:14:55 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:22 UTC