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

On Mar 15, 2006, at 5:55 AM, Bjoern Hoehrmann wrote:

>
> * Jonas Sicking 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.

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.

For SVG's event listener attributes we could either say UAs MUST NOT  
do this or take one of options 1 or 2.

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.

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

Regards,
Maciej

Received on Wednesday, 15 March 2006 21:47:12 UTC