The "initialization" steps for Web browsers

Ian Hickson ian at
Wed Jul 23 10:47:35 PDT 2014

On Tue, 22 Jul 2014, Allen Wirfs-Brock wrote:
> > 
> > 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.

(Just to clarify: the text in the HTML spec right now is clearly bogus and 
needs rewriting. My questions here are just an attempt to find out what it 
should be rewritten to.)

> 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.

I mean that you take the FunctionBody production, adjust it to include the 
logic for automatic semicolon insertion, and then that's what an Event 
Handler content attribute needs to match. Note that the text you quote 
here is a document conformance criteria, not a user-agent conformance 
criteria, so it doesn't imply anything about what browsers do.

> If the latter, than you probably don't need to say anything because ASI 
> is part of the ES parsing process.

What I'm trying to say in the text you quote is whether or not something 
is valid. I can't just say that it has to match the FunctionBody 
production, because when ES parses it inserts semicolons, so the strings 
don't always actually match the productions per se. I could also phrase it 
using terminology more like what ScriptEvaluationJob step 2 does, would 
that be better? I'd ideally like to avoid having to mention either 
semicolons or early errors or any of that stuff.

> 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.

"uncompiled script body" is an opaque term unrelated to "ScriptBody".

> 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.

I can't do that, because that would enable people to do things like end 
their code with a "//" and have it comment out the trailing "}", or put a 
"} function () {" in the middle of their code and have it somehow parsed 
into two functions, or whatnot. In general I think trying to take the 
author's input and manipulate it ends up being a really dangerous 
practice. Better to imply it somehow in prose, IMHO.

> And even with that I'm still uncomfortable will how you are trying to 
> manually wireup the scope of the function using the body.

Me too.

> Perhaps a way out of this is to for Annex B of ES6 
> to actually define the syntax and semantics of an AttributeEventHandler 
> function and provide abstract the operations you can call to create one.

That would be fantastic, sure! Is that an option?

> 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.

Well, the difficult thing here is that the parsing and the execution have 
to be quite separate. The parsing has to happen just once. If it happens 
as part of event handling, then that will also involve execution; but it 
can also happen as part of just the author getting the value of the 
handler. In either case, if the value is subsequently fetched, the same 
Function object must be returned each time. Also, when creating the 
Function object it's important that we construct the lexical scope 
carefully, and the arguments differ based on context.

When it comes to executing it, it should just be equivalent to normal 
browser-to-script function callbacks.

If you can provide a mechanism that parses the function body, I'd be happy 
to defer to it. The inputs to this would be the string to parse as the 
function body, the names of the argument(s), and a Lexical Environment. 
The output would be a Function object or an error.

> I didn't see where in the process of invoking an event handler that you 
> call the [[Call]] internal method of the callback function.

That's the open issue that says "In this step, invoke means to run the 
jump to a code entry-point algorithm". The "jump to a code entry-point" 
algorithm is here:

The line that calls [[Call]] is "Make the appropriate script execution 
environment specified by context execute the s's code entry-point". I 
can't actually mention [[Call]] explicitly because it might not be 
JavaScript that I'm executing.

I'm hoping we can more explicitly glue this together at some point, maybe 
with WebIDL defining a generic term that is then explicitly mapped to 
[[Call]] in the ECMAScript/WebIDL binding in the WebIDL spec.

> 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.

Nah, that's all handled by the DOM spec. It can't be all a single ES job 
because, if nothing else, it could be interleaving ES and non-ES handlers.

> 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.

Unfortunately the English language has too few nouns. :-) This problem 
occurs all the time. For example, ES uses the term "element" for things 
that aren't HTML Elements; CSS uses "properties" for things that aren't JS 
properties; the word "attribute" is used for both WebIDL attributes and 
HTML content attributes, which are distinct even though there's usually a 
1:1 mapping between them; the term "media type" means something different 
in a MIME context than a CSS context, the term "selector" is used in the 
ES grammar to mean something unrelated to CSS Selectors; the word 
"resource" means something different in almost every Web spec; the word 
"character" sometimes means multiple different things within a single spec 
(and rarely does it mean what it sounds like it means -- ES is a 
particularly prominent offender in that realm!); the terms "user" and 
"author" mean different things in different specs, etc...

As far as "object" goes, you can pretend that all things called "objects" 
in the HTML spec are ES Objects of one kind or another, and it's just that 
some of them aren't exposed to author script.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

More information about the es-discuss mailing list