Re: onFoo and friends (ACTION-70)

On Mar 28, 2006, at 7:43 AM, Anne van Kesteren wrote:

>
> I just finished reading the thread http://lists.w3.org/Archives/ 
> Public/public-webapi/2006Mar/thread.html#msg131 on the scope chain  
> of onFoo events and the like. It seems that if we ever are going to  
> define a specification regarding "Everything you always wanted to  
> know about scripting and event handling in HTML and other formats  
> but were afraid to ask 1.0" (opted by Björn in #webapi) there are  
> some things that need to be defined:

I think my proposal covered some of these.

>  (1) At what point is `onfoo` in `<x onfoo="return false">`
>      converted to an EventListener.
>
> Some people have suggested that this should be live, e.g. doing  
> `x.setAttribute("onfoo", "return true")` should update the  
> EventListener. I think other people have argued for only converting  
> it to an EventListener at insertion time. So everytime you do  
> `appendChild(x)` where x has `x.setAttribute("onfoo","test()")` or  
> when the document is first loaded. Just doing `x.setAttribute()` if  
> x is already in the doucment would have no effect.

It should be live. It is in existing browser implementations. I think  
we should reject the proposals to change this.

>
>  (2) Is `onfoo` in `<x onfoo="">` and `x.onfoo` the same?
>
> As in, does updating one update the other and vice versa?

Updating <x onfoo=""> alters x.onfoo, but not vice versa (well,  
except in IE, due to their broken attribute model).

>  (3) How does `return false` or `return true` affect
>      `e.preventDefault()` for various values of
>      `e.type`?

for "mouseover" events, returning true prevents default, otherwise  
returning false prevents default. These must be precisely the values  
"true" and "false".

>  (4) Does (3) solely apply to HTML or to other languages as
>      well?

Current SVG-only implementations with event listeners don't do (3),  
but they also have "evt" instead of "event" and might not do scope  
chain alteration or "this" binding.

>  (5) How to organize the specification?
>
> Björn suggested to make the specification generic and just state  
> the rules on how languages could define onfoo attributes using the  
> terminology provided in the specification. The specification would  
> have one, normative, example of doing so. Namely how it applies to  
> HTML. Of course, only normative for implementations that do HTML...

I would write the spec just for HTML unless we expect other languages  
to follow (call it "HTML Events" maybe).

>
>  (6) What to do with
>      `x.removeEventListener('foo', x.onfoo, false)`?
>
> http://www.w3.org/mid/191127F9-AB91-482C- 
> A141-6994322D7749@apple.com outlines a solution to this problem  
> although I think HTML should be reworded to something else, more  
> language neutral.

In current implementations, that won't remove the listener. I'm not  
sure what there is to solve other than stating that.

>  (7) What about `this`? In HTML form controls there is
>      some special behavior that should be dealt with...

"this" binding is the same as for other listeners.

> http://whatwg.org/specs/web-apps/current-work/#event has some  
> information on the subject. (And on this subject in general.)

I think what it says is not quite correct. For example:

"In the ECMAScript DOM binding, the ECMAScript native Function type  
must implement the EventListener interface such that invoking the  
handleEvent() method of that interface on the object from another  
language binding invokes the function itself, with the event argument  
as its only argument."

Function does not implement the EventListener interface secretly, and  
it doesn't make sense to describe it that way. In fact if you added a  
function with an actual handleEvent function property, then the  
handleEvent method would get called, not the function.

"If the function returns false, the event's preventDefault() method  
must then invoked."

That's not true for listeners added with addEventListener, only for  
elt.onfoo and <elt onfoo=""> listeners ("HTML Event Listeners" and  
"HTML Attribute Event Listeners" in my terminology).

Also, "this" binding is not defined at all (or rather given as a  
statement of fact in passing).

But the fact that the form and document should be in the scope chain  
as well is something I missed.

>  (8) What about attributes that are set on some elements
>      (like BODY) where the EventListener ends up
>      somewhere else (like Window)?

Not sure what to do about these.

> There is probably more...

If we write a spec like this I'd be happy to help (possibly even co- 
edit), but I need to get Window in better shape first.

Regards,
Maciej

Received on Tuesday, 28 March 2006 21:46:10 UTC