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

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11977

--- Comment #6 from Allen Wirfs-Brock <allen@wirfs-brock.com> 2011-03-05 01:16:08 UTC ---
(In reply to comment #5)
> 
> I really would like to avoid defining a source transformation because that
> often ends up having far more complicated side-effects than one would expect.
>

I actually think that in some of these cases source transformation is going to
be more reliable and durable then hooking into the spec. language.  Basically,
the source language and its semantics are managed to ensure a very high degree
of backwards compatibility while the internal specification language changes
from edition to edition as necessary to define new constructs that are
introduced into the language.  The internal spec. language historically has not
been design with long term stability as a one of its goals.

Here is a first cut at defining event handlers as such a transformation:
1  Set the corresponding event handler to null.
2  Set up a script execution environment for JavaScript.
3  Let /body/ be the event handler context attribute's new value.
4  If /body/ is can not be parsed as /FunctionBody/ then abort these steps.
5  Let /F/ and /E/ be the text of any two ECMAScript identifiers that do not
occur in /body/.
6  If the element has a form owner let /prefix/ be the string "(function
(__F__, __E__) {with (__F__) with (__E__) {" otherwise let /prefix/ be the
string "(function (__E__) {with (__E__) {" .
7  Replace all occurrences of "__F__" and "__E__" within /prefix/ with the
values of /F/ and /E/ respectively
8  If the attribute is the onerror attribute of the Window object let
/funcHeader/ be the string "return function (event, source, fileno) {"
otherwise let /funcHeader/ be the string "return function (event) {".
9  Let /handlerMaker/ be a string consisting of the in order concatenation of
/prefix/, /funcHeader/, /body/, and "}}})".
10 Create an ECMAScript language script from the node on which the attribute is
being set using the string value of /handlerMaker/ as the script source.
11 Let /result/ be the value of the initial code entry-point of this script. If
an exception was raised, let /result/ be void instead.
12 If /result/ is void, abort these steps.
13 If the element has a form owner call the function that is the the value of
/result/ passing the element's form owner , and the element's object as
arguments;
14 otherwise call the function that is the the value of /result/ passing  the
element's object as the sole argument.
15 Set the corresponding event handler to  the value returned by the function
call in step 13 or 14.


Note: The script text for a /handerMaker/ for an element with a formowner and
which is not a onerror attribute of a Window object:

// If "__F__" or "__S__" occur in <<body>> they are replaced with identifiers
that do no occur.
(function (__F__, __S__) {
   with (__F__) with (__S__) { return
       function (event) {
            <<body>>
       }
   }
})

The result value computed in step 11 is the outer function above.
Step 13/14 calls that function to create a closure of the inner function closed
over the optional form owner and the element's object.  That function is the
event handler value.
------------------------
I think the above formulation is clearer and is going to be much more durable.
I see minimal risk of unintended side effects and it will be easier to analyze
for such than re-purposed ES5 specification pseudo-code.

> What I mean by a "hook" is just that the ES spec could say "When a
> specification needs to create a foo using a list of arguments bar and a body
> baz, it must follow these steps, which return a quux and a gizmo: 1. do
> something, 2. do something else, 3. do yet more things". Then instead of having
> to reference specific sections or talk about specific grammar constructs, we
> can just say "and then create a foo as defined in the ES spec".
> 
> There's a number of places where hooks like that would be useful.

The idea of stable interface points between specifications is an interesting
one. Where possible, I still think an "as if" transformation to the source
language is preferable but for situations where that isn't expressive enough
then a stable inter-specification interface my be a good way to make durable
connections between specs. 
However, we should probably continue this discussion somewhere other than in
this bug.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Saturday, 5 March 2011 01:16:15 UTC