W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2010

Re: Partial review of DOM 3 Events

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Wed, 6 Oct 2010 12:21:31 -0700
Message-ID: <AANLkTima2j+5ywV0pfWRH-ZwwpThwRE3tv8ehywqfd4J@mail.gmail.com>
To: Olli@pettay.fi
Cc: Simon Pieters <simonp@opera.com>, "www-dom@w3.org" <www-dom@w3.org>
On 10/6/10, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:
> On 09/10/2010 12:58 PM, Simon Pieters wrote:
>> Here's a partial review of DOM 3 Events
>> http://www.w3.org/TR/2010/WD-DOM-Level-3-Events-20100907/
>> What's the use case for extended feature strings for event types
>> (hasFeature('Events.click', ''))? Opera, WebKit and Gecko don't support
>> this. [1]

The behavior is interoperable, including in IE9, though totally
useless, as the result is always false. This strategy cannot be used
for detecting events.

> Use case is to detect whether the browser claims to dispatch such
> (trusted) events.
> Currently
>      if (element.onfoo) { ... }
> is occasionally used for detecting support for some events, but that
> doesn't really work since not all events have onfoo event listeners.
That approach would only be applicable to event handler properties. It
doesn't work if the event handler is null. Null is the default value
specified in HTML 5 but in Gecko, event handler is not initially
present, e.g. typeof document.onclick == "undefined".

The "isEventSupported" project mentioned in a previous thread (you
might recall the name of that thread) makes use of that, but has
another crucial step involved: using setAttribute("onfoo", ";");
(though I recall the actual code uses a totally useless return

Thanks for raising these issues.

Received on Wednesday, 6 October 2010 19:22:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:16 UTC