RE: [DOML3Events] ACTION-267 Proposal for event iterator

From your link, it appears the only reason this was dropped was because the folks in discussion at the time thought the only use case for this feature was Accessibility venders (ATs).

=====
JS: I don't see the point in time spent on hasEventListener etc. as we don't need them.
RB: so the use case for them could be that AT tools could introspect another DOM.
MJS: said it was a convincing argument but not enough to solve the problem.
<darobin> chaals, http://www.w3.org/2005/06/tracker/webapi/issues/17

JL: If the only use case for AT tools, then it should be in a seperate AT spec. that includes everything for AT tools.
JS: I agree it's not the place of the DOM to define plugin api's which this seems to be.
CMN: So you don't think that's how AT should work?
JS: I think that AT shouldn't be in DOM spec, as the DOM spec is for page authors.
... AT needs to enumerate all listeners and figure out "what it does".
CMN: The argument likely to come back is being able to find out event listeners would be a huge step forward.
JS: so I'd ask why have it in a DOM specification?
CMN: their rationale is so that it will get done...
JL: AT's can already do this.
... so speccing it as part of DOM3 for the one use case is overkill.
RB: So am I hearing that dropping it is a good idea due to not really meeting the use case and there being many other issues.
RESOLUTION: keep stopImmediatePropogation
... drop willTriggerNS and hasEventListener
=====

I've been specifically requested to add such support into IE by various customers. Most of their use-cases involve script that is trying to 'clean-up' event handlers for which they did not set, and do not have a pre-existing handle to the function callback.

The proposed API allows enumeration of the function callbacks (which is what I mean by EventListener objects--native JS functions in EmcaScript).

As for issue 5, we're still trying to figure out if event handlers specified via onclick=" " in HTML should be counted in the enumeration (this is useful to spec regardless of the existence of this API, as you may want to do:
[EventTarget].removeEventListener('[type]', [EventTarget].on[type], bool);

and there is discussion as to whether that's possible or not.

As for issue 11, only "public" events should be exposed through this mechanism--this should not be used for getting internal listeners--such functionality is a security risk--I agree.


-----Original Message-----
From: public-webapi-request@w3.org [mailto:public-webapi-request@w3.org] On Behalf Of Anne van Kesteren
Sent: Wednesday, April 09, 2008 1:13 PM
To: Travis Leithead; Doug Schepers; Web API public
Subject: Re: [DOML3Events] ACTION-267 Proposal for event iterator


On Wed, 09 Apr 2008 21:54:56 +0200, Travis Leithead
<travil@windows.microsoft.com> wrote:
> // New in DOM Level 3:
> typedef sequence<EventListener> EventListenerList;

The EventListener object only has a handle() method unless I'm missing
something obvious. Having a list of those does not exactly seem useful. I
think that's why DOM Level 3 Events once had a hasEventListenerNS() method.

We resolved to remove hasEventLisenerNS here:

http://lists.w3.org/Archives/Public/public-webapi/2006Mar/att-0092/23-webapi-minutes.html


This proposal would also need to deal with the various issues raised here:

   http://www.w3.org/2005/06/tracker/webapi/issues/5

   http://www.w3.org/2005/06/tracker/webapi/issues/11



--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Wednesday, 9 April 2008 21:17:42 UTC