- From: Charles McCathieNevile <chaals@opera.com>
- Date: Wed, 29 Apr 2009 01:02:39 +0200
- To: João Eiras <joaoe@opera.com>, "Jonas Sicking" <jonas@sicking.cc>, "Travis Leithead" <Travis.Leithead@microsoft.com>
- Cc: "Mike Wilson" <mikewse@hotmail.com>, "public-webapps@w3.org" <public-webapps@w3.org>
Reminder that DOM 3 discussion has moved to www-dom - I will collate the thread here and forward it there. If you are not on that list, please subscribe by sending mail to www-dom-request@w3.org with "subscribe" in the subject cheers Chaals On Tue, 28 Apr 2009 23:41:08 +0200, João Eiras <joaoe@opera.com> wrote: > On Tue, 28 Apr 2009 21:57:10 +0200, Jonas Sicking <jonas@sicking.cc> > wrote: > >> On Tue, Apr 28, 2009 at 12:50 PM, Travis Leithead >> <Travis.Leithead@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. -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Received on Tuesday, 28 April 2009 23:03:31 UTC