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

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
element->document->window
for all elements but form controls. For these the chain is
formControl->form->document->window

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