- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 16 Mar 2006 13:55:34 -0800
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- Cc: Web APIs WG <public-webapi@w3.org>
Bjoern Hoehrmann wrote:
> * Jonas Sicking wrote:
>> 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.
>
> If I were to write a tutorial for this, I'd say that returning values
> from such scripts triggers confusing, non-interoperable HTML quirks in
> some implementations, don't do that...
What quirks does returning false trigger?
I would have thought that returning false (or true depending on the
event) is a much more reliable way to prevent the default action then
calling .preventDefault(). This since the former works in IE.
>> So the resulting code would be something like:
>>
>> function(event)
>> {
>> if (HTML_LISTENER.call(this, event) ==
>> (event.type == "error" || event.type == "mouseover"))
>> event.preventDefault();
>> }
>
> Note that some browsers allow to uncancel the event by returning other
> values as the event bubbles up the tree.
Yes, we talked about this and I suggested that we do not support that
behaviour and noone seemed to object to that.
> And onerror="" is different
> from most other onfoo="" attributes, in Mozilla the script would be
> called with three arguments instead of one, and none of those arguments
> is an Event object, for example.
Good point. Are we defining the error event? If not then we just need to
mention "mouseover" as the exception.
/ Jonas
Received on Thursday, 16 March 2006 21:55:37 UTC