On Jul 22, 2014, at 12:32 PM, Ian Hickson wrote:
> On Mon, 21 Jul 2014, Allen Wirfs-Brock wrote:
>>
>> So if there is no ES code to execution prior to that first user action
>> then you might defer the whole 8.5 initialization process until then.
>
> Well, loading an HTML file involves manipulating the Window global object,
> so I need the realm initialised before I start that.
At the implementation level it may make sense to distinguish between the global
Window state and the actual ES Window object.
Don't know whether there might be a reason to do this at the spec. level.
>
>
>> However, if there is some other way to acquire and execute ES code prior
>> to such a user action (for example, FF chrome code, a startup script,
>> etc.) when you would have to do 8.5 initialization earlier. You might
>> use the "first Realm" for that code or you might use the "first Realm"
>> as sort of system utility realm, if you have a use for such a thing.
>
> Those are out of scope of the HTML spec. I think the realm created by 8.5,
> in the context of HTML, will never be used. (I expect implementations just
> won't create one, in practice, but that's an implementation detail.)
>
Or use it for the first window.
>
> Do you have any opinion on how I should handle attribute event handlers?
> They are conceptually FunctionBodys with specific parameters, and they are
> parsed the first time they are invoked, but can be reinvoked later without
> being reparsed. Currently the HTML spec hand-waves this using "code entry
> points" but those don't really map to anything in ES.
You say: "Event Handler content attributes ... match the FunctionBody
production after automatic semicolon insertion." Are you trying to say
something special about ASI,. For example, that ASI is not applied when
parsing attribute event handlers. Or are you just saying that the normal rules
of ASI apply. If the latter, than you probably don't need to say anything
because ASI is part of the ES parsing process. If you really mean that ASI
rules are not applied you need to be more explicit about that (and it probably
raises issues of ES spec. integration).
Also, you defined "internal raw uncompiled handler" as containing a "uncompiled
script body". However, in the ES6 spec. ScriptBody is an actual grammar
production that is different from FunctionBody.
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-scripts Everything
else in this section of your spec. seems to be saying that event handlers are
function bodies, so this is hopefully just a terminology issue.
I notice that you currently (step 8 of getting current value of event handler)
you parse the function body in isolation from a function expression header.
You can't really do that in ES6 as there are early error rules at the level of
FunctionExpression that need to be considered with the body. I think, you need
to wrap the FunctionBody with the boilerplate source code of a
FunctionExpression, including an appropriate formal parameter list. And even
with that I'm still uncomfortable will how you are trying to manually wireup
the scope of the function using the body.
Perhaps a way out of this is to for Annex B of ES6
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-additional-ecmascript-features-for-web-browsers
to actually define the syntax and semantics of an AttributeEventHandler
function and provide abstract the operations you can call to create one. I
imagine that we would want to process the creation of these functions similar
to an eval call where we synchronously parse/compile and do not go through the
async ScriptEvaluationJob mechanism.
I didn't see where in the process of invoking an event handler that you call
the [[Call]] internal method of the callback function. This is essential for
setting up the local environment of the function you are invoking. You also
need to handle any exceptions that come back from the [[Call]]. BTW, I'm also
assuming that a batch of events would be handled as a single ES job and that
the abstract operation for that job would sequence through setup the the script
settings for each event handler and then call it.
Finally, and a bit of an aside, I find it somewhat confusing that there are
entities you call objects (for example, script settings objects) that don't
seem to actually need to be exposed as ECMAScript objects. It causes me to be
continuously asking myself whether something is a real ES object or just part
of the specification/platform state that ES code never directly sees. In the ES
spec. we deal with this by distinguishing between records and objects. Where
records corresponds to state that is never directly exposed to ES code.
Overall, my sense is that we are inching in a good direction but that there is
a fair amount of work that is still need to enable the HTML and ES specs to
smoothly plug together.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
