The "initialization" steps for Web browsers
allen at wirfs-brock.com
Tue Jul 22 16:21:23 PDT 2014
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss