W3C home > Mailing lists > Public > public-webapi@w3.org > March 2006

Re: ACTION-70: Define the scope chain of onFoo events reference issue-1

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 14 Mar 2006 17:04:03 -0800
Message-ID: <44176803.8070506@sicking.cc>
To: Maciej Stachowiak <mjs@apple.com>
Cc: "Web APIs WG (public)" <public-webapi@w3.org>

Maciej Stachowiak wrote:
>>> Here's brief outlines of the behavior I would propose. I have not 
>>> tested thoroughly or written any of this up in formal language, so 
>>> please let me know which ones need testing and formal language.
>>> 1) The attribute text is coverted to a function as if it were the 
>>> result of the following expression evaluated in global scope, where 
>>> ELT is the DOM object representing the element:
>>> (function() { with(ELT) { return function(event) {  ...contents of 
>>> attribute here... } } })()
>> There is need for additional code in here to deal with the return 
>> value, i.e. that returning false should call .preventDefault. Other 
>> then that I agree with this.
> Ugh, you're right, I forgot about this.I think the preventDefault 
> behavior is related to being an HTML event listener (set via <img 
> onclick="..."> or someImg.onclick=... ), not specifically a property of 
> being an attribute-created listener, which means this special behavior 
> can't be part of the function itself. We need an extra level of 
> indirection to define what happens when an HTML event listener is added 
> either via element attribute or JS property.
> A first stab at it would be that it's like calling addEventListener with
>    function(event) { if (HTML_LISTENER.call(this, event) == false) 
> event.preventDefault(); }
> Where HTML_LISTENER is the html event listener function, as created from 
> an attribute or assigned to the HTML DOM property. This is then used as 
> F in the language below.

Do we really only want to do this for HTML attributes? It's not a 
particularly beautiful thing to do, but on the other hand it's always 
nice when things behave everywhere.

I don't necessarily have a strong opinion either way.

>> However we should probably also define the scope chain for elements. 
>> This should clearly ideally have lived in another spec, but I guess 
>> we're stuck with having it in events for now?
> Scope chain for elements? I don't think they have a scope chain, as they 
> are not callable. Maybe I am missing someting...

So we have decided that the element is the top of the scope chain. 
However, what does the rest of the chain look like? I.e. if a property 
is not found on the element, where do you look after that?
This is decided by the [[parent]] of the element object, and then that 
objects [[parent]] property and so on.

Currently in HTML the chain is
for all elements but form controls. For these the chain is

This is probably something that we should define, painful as it is.

>>> 5) addEventListener does not alter any function parameters passed to 
>>> it. In particular it does not alter the scope chain.
>>> 6) I already came up with language for this. In brief my proposal was 
>>> to define this as equivalent to adding an EventListener created by 
>>> the expression { handleEvent: function(event) { 
>>> F.applyTo(event.currentTarget, [event]); } } where F is the function.
>> I would prefer if we used "call" rather then "apply" to make it clear 
>> that only one parameter is passed. It would also make it cheaper for 
>> someone implementing this literally.
> How about:
>   { handleEvent: function(event) { F.call(event.currentTarget, event); } }

Looks great!

/ Jonas
Received on Wednesday, 15 March 2006 01:04:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:20 UTC