Re: [DOML3Events] ACTION-267 Proposal for event iterator
also note that this would mean that a web site could try to knock out other web based mashups that it didn't like. i'm sure that browser vendors can provide an api for their debugging clients, but this feature shouldn't be exposed to web content.
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-requ...@w3.org [mailto:public-webapps-requ...@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
Re: [DOML3Events] ACTION-267 Proposal for event iterator
On Tue, Apr 28, 2009 at 12:50 PM, Travis Leithead travis.leith...@microsoft.com wrote: 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. That is the initial problem that we in firefox would have with this. The other problem is a lack of use cases. All the ones I have heard so far has been to implement various aspects of accessibility technology. However this can be done using internal interfaces in the UA. No need to expose anything to web pages. / Jonas
Re: [DOML3Events] ACTION-267 Proposal for event iterator
On Tue, 28 Apr 2009 21:57:10 +0200, Jonas Sicking jo...@sicking.cc wrote: On Tue, Apr 28, 2009 at 12:50 PM, Travis Leithead travis.leith...@microsoft.com wrote: 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. That is the initial problem that we in firefox would have with this. The other problem is a lack of use cases. All the ones I have heard so far has been to implement various aspects of accessibility technology. However this can be done using internal interfaces in the UA. No need to expose anything to web pages. / Jonas Also, this would obviously conflict with client side user scripts which I would not like to see :), because then a webpage would clear all the local script listeners, while it should really be the user to say how the site should behave ultimatelly.
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
