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

>>>> 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.
> 
> Well, browsers currently do it and it would not be feasible for them to 
> stop. So the spec must be written to at leat allow this, even if it does 
> not mandate it. And since browsers have to do it anyway, it may as well 
> be in the spec, although we could say content authors SHOULD NOT rely on 
> it. On the other hand, "return false" is a lot more succinct than 
> "event.preventDefault()" so I can see why content authors may be tempted.

My question was not "should we put this in the spec for html" but rather 
"should we say that this applies to on* attributes in all languages or 
just html".

>>>> 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.
> 
> All right, good point. I think we can define this with multiple levels 
> of "with" statements and special-case form controls. Although I think 
> Safari puts only the element itself on the scope chain and we haven't 
> seen many problems with this. We'll need some test cases to verify the 
> behavior.
> 
> The window does not need to be mentioned explicitly since it is the 
> global object so will always be at the bottom of the scope chain, but 
> the document and form need addressing.

Well.. it is the global object because it is the bottom of the scope 
chain, not the other way around (I believe).

Would be great if you could check what scope-chain safari uses. I think 
a fair amout of pages would break if not at least the form was in the 
scope chain.

/ Jonas

Received on Thursday, 16 March 2006 01:29:59 UTC