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: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 15 Mar 2006 13:27:42 -0800
Message-Id: <926BE199-4F39-414D-B35E-A249C054449B@apple.com>
Cc: "Web APIs WG (public)" <public-webapi@w3.org>
To: Jonas Sicking <jonas@sicking.cc>

On Mar 14, 2006, at 5:04 PM, Jonas Sicking wrote:

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

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.

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

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.

Received on Wednesday, 15 March 2006 21:27:49 UTC

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