- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Wed, 6 Oct 2010 12:21:31 -0700
- 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 statement). Thanks for raising these issues. Garrett
Received on Wednesday, 6 October 2010 19:22:05 UTC