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

I think this was dropped because it would allow general web apps to inspect (and remove?) event handlers that were registered by code running in extensions or by the browser itself.

In general, this is a great idea for debugging or extensions, but not so great in web app deployment scenarios.

Folks can feel free to correct me if I'm way off base.

-Travis

-----Original Message-----
From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Mike Wilson
Sent: Saturday, April 25, 2009 2:36 AM
To: public-webapps@w3.org
Subject: RE: [DOML3Events] ACTION-267 Proposal for event iterator

Following up on last year's discussion on adding support for querying DOM elements about already registered event handlers:

Travis Leithead wrote on Apr 09, 2008; 08:07pm
> In considering a design for the event iterator (allow devs to
> enumerate what events have been _added_ via addEventListener to a
> given object), I looked at two general
> approaches:
>
> 1) Defining a new collection on every object that supports the
> EventTarget interface
> 2) Defining a 'getNextEvent' function for every object that supports
> the EventTarget interface
> 3) Defining a function that returns a static/dynamic list of event
> handlers for a given object that supports the EventTarget interface
<rest of conversation snipped>

Action page:
http://www.w3.org/2006/webapi/track/actions/267

Mail thread view on nabble:
http://www.nabble.com/-DOML3Events--ACTION-267-Proposal-for-event-iterator-t
d16593177.html#a16691378

Was any consensus ever reached and what's the status of this suggestion now?

Personally I think this feature is a very natural part of the DOM API and believe there needs to be very good reasons not to include it.

Best regards
Mike Wilson

Received on Tuesday, 28 April 2009 19:48:46 UTC