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: Wed, 15 Mar 2006 20:57:18 -0800
Message-ID: <4418F02E.6060802@sicking.cc>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, Web APIs WG <public-webapi@w3.org>

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.


> 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 

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:

   if (HTML_LISTENER.call(this, event) ==
        (event.type == "error" || event.type == "mouseover"))

Alternativly we could say that

   if (HTML_LISTENER.call(this, event) == true)

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

   if (HTML_LISTENER.call(this, event) == false)

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

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