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

Maciej Stachowiak wrote:
>>>>> 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, this behavior is pretty much limited to HTML onfoo="" attributes,
>>>> you don't have it for SVG onfoo="" attributes in most implementations,
>>>> or addEventListener listeners, or <script> listeners, ... and since you
>>>> would ultimiately have to change handleEvent's signature, I don't think
>>>> that is a good idea.
>>>
>>> My suggestion was only to do this for onfoo attributes. Not for
>>> addEventListener calls or <script> listeners. So there is no need to
>>> change the signature of handleEvent.
>>
>> I think the return value should be ignored everywhere (to the extend
>> possible). Current SVG implementations typically don't support this,
>> it's not easy to understand given that the effect depends on the type
>> of event, and the more it works, the more people expect it to work,
>> so they'd likely be surprised if this works for svg onclick="" but
>> not for <svg:handler>, for example.
> 
> In my opinion, the viable options are:
> 
> 1) Say that HTML UAs MUST offer this behavior but authors SHOULD NOT 
> rely on it.
> 2) Say that HTML UAs MAY (or event SHOULD) offer this behavior or MAY 
> ignore the return value but authors SHOULD NOT rely on either.

Why not simply

3) Say that HTML UAs MUST offer this behaviour

I don't see a point in telling people not to use it. It's there and it's 
never going to go away. So if people think it's practical, why not let 
them use it.

> We can't write the spec to leave out the possibility of doing the 
> preventDefault thing, since it is needed for compatibility with existing 
> content and that is one of the main reasons we want to specify event 
> listener attributes at all.

Agreed.

> Personally, I prefer #1 for HTML because it's poor practice to have 
> MAY-level requirements that in practice most UAs will be doing and 
> therefore new UAs would really need to do it too, to be interoperable.

Agreed. Though I'd say 3).

>>>> Note that this isn't as simple as if the return
>>>> value is false: preventDefault; what you do depends on the event type.
>>>
>>> Are you referring to the fact that for the mouseover event (or was it
>>> some other mouse* event?) the return value should be true to call
>>> preventDefault?
>>
>> Well, something like that. http://esw.w3.org/topic/List_of_events has
>> many events where I don't know what the effect would be...
> 
> It would be ugly but not impossible to provide a list of events where 
> the sense is opposite.

In mozilla we treat the return value different for exactly three events:

For "error" and "mouseover" returning true rather then false will call 
preventDefault.

For "beforeunload" we use the returnvalue in a confirmation dialog 
asking the user if he really wants to leave the page. However, since DOM 
level 3 Events doesn't include the beforeunload event we don't need to 
worry about that yet.

So the resulting code would be something like:

function(event)
{
   if (HTML_LISTENER.call(this, event) ==
        (event.type == "error" || event.type == "mouseover"))
      event.preventDefault();
}

Alternativly we could say that

function(event)
{
   if (HTML_LISTENER.call(this, event) == true)
      event.preventDefault();
}

is used for "error" and "mouseover", and

function(event)
{
   if (HTML_LISTENER.call(this, event) == false)
      event.preventDefault();
}

is used for all other HTML on* handlers.

At first I was a bit confused why calling .preventDefault on the 
errorevent mattered at all, but it turns out that this event is 
dispatched when a JS-exception is thrown and not catch'ed. The default 
action of this event is to post a message to the JS-console.

/ Jonas

Received on Thursday, 16 March 2006 04:57:17 UTC