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

[Charles McCathieNevile-2]

(forwarded from public-webapps - I will add the current replies from there  
to this thread)

------- Forwarded message -------
From: "Mike Wilson" <mikewse@...>
To: public-webapps@...
Cc:
Subject: RE: [DOML3Events] ACTION-267 Proposal for event iterator
Date: Sat, 25 Apr 2009 11:35:54 +0200

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



--
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

[Charles McCathieNevile-2]

> Jonas wrote:
> <Travis.Leithead@...> 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.

On Wed, 29 Apr 2009 01:05:34 +0200, Charles McCathieNevile
<chaals@...> wrote:

> (forwarded from public-webapps - I will add the current replies from  
> there to this thread)
>
> ------- Forwarded message -------
> From: "Mike Wilson" <mikewse@...>
> To: public-webapps@...
> Cc:
> Subject: RE: [DOML3Events] ACTION-267 Proposal for event iterator
> Date: Sat, 25 Apr 2009 11:35:54 +0200
>
> 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
>
>
>

--
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

[Charles McCathieNevile-2]

Jonas Sicking wrote on 28 april 2009 21:57:
> On Tue, Apr 28, 2009 at 12:50 PM, Travis Leithead
> <Travis.Leithead@...> 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.
>  That is the initial problem that we in firefox would have with this.

As you pointed out last year, it is a "nice to have" but not crucial
to let the native browser code be able to use the same interfaces as
web page scripts. From an author's point of view I would expect only
other "user code" registered event handlers to be enumerated by the
event iterator, not browser or extension handlers.

Actually, I think a spec for the event iterator should explicitly say
that these MUST not be included in the enumeration.

Does that take care of the security issues or am I missing something
else?

The DOM is pretty much up for taking for any script allowed inside, so
are there really any new and dangerous things that can be done just
because event handlers are listable (and therefore removable), that
cannot be implemented by other means?

> The other problem is a lack of use cases.

In my view the API isn't complete without being able to enumerate a
collection that already has add/remove-methods, and as stated earlier
I think the main question should be what good reasons there are not to
include it. Use cases acknowledged by the browser literati or not, I
think this a matter of API completeness.

Personally I have been missing this feature when doing client-side DOM
transformations, f ex transforming more simple element hierarchies
into widget-like experiences and wanting to move/re-register existing
event handlers into the new element structure. This currently requires
the initial structure to use DOM0 event attributes.

Best regards
Mike Wilson


On Wed, 29 Apr 2009 01:05:34 +0200, Charles McCathieNevile  
<chaals@...> wrote:

> (forwarded from public-webapps - I will add the current replies from  
> there to this thread)
>
> ------- Forwarded message -------
> From: "Mike Wilson" <mikewse@...>
> To: public-webapps@...
> Cc:
> Subject: RE: [DOML3Events] ACTION-267 Proposal for event iterator
> Date: Sat, 25 Apr 2009 11:35:54 +0200
>
> 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
>
>
>

--
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

[Boris Zbarsky]

> Does that take care of the security issues or am I missing something
> else?

It seems to, but I'm also interested in specific use cases that this
ability solves.

> The DOM is pretty much up for taking for any script allowed inside, so
> are there really any new and dangerous things that can be done just
> because event handlers are listable (and therefore removable), that
> cannot be implemented by other means?

Not if you define "event handers" narrowly as you did above; it does
mean that some obvious uses people have had for this in the past are no
longer possible, which is why the use cases it still solves are
something I want to know about.

> In my view the API isn't complete without being able to enumerate a
> collection that already has add/remove-methods, and as stated earlier
> I think the main question should be what good reasons there are not to
> include it.

Sorry, I'm not sure I buy this.  The API should, generally speaking, be
as small as possible while still fulfilling its purpose.  Anything above
that adds complexity for both the implementor and the API consumer
(conceptual complexity in the latter case).

The "while fulfilling its purpose" part is key.

> Personally I have been missing this feature when doing client-side DOM
> transformations, f ex transforming more simple element hierarchies
> into widget-like experiences and wanting to move/re-register existing
> event handlers into the new element structure. This currently requires
> the initial structure to use DOM0 event attributes.

Thank you for the use case.  Did you control all the event listeners
involved, or did you have some way of guaranteeing that the transplanted
listeners would still function correctly in the new location?

-Boris

[Boris Zbarsky]

> Best regards
> Mike Wilson

Oh, and I'd love to know how that mail ended up with:

   From: "Charles McCathieNevile" <chaals@...>
   Organization: Opera Software

given the signature.

-Boris

[Jonas Sicking-2]

>> Personally I have been missing this feature when doing client-side DOM
>> transformations, f ex transforming more simple element hierarchies
>> into widget-like experiences and wanting to move/re-register existing
>> event handlers into the new element structure. This currently requires
>> the initial structure to use DOM0 event attributes.
>
> Thank you for the use case.  Did you control all the event listeners
> involved, or did you have some way of guaranteeing that the transplanted
> listeners would still function correctly in the new location?

Also, would your example work even if the API only enumerated
page-added event listeners, and not listeners added by the
implementation or user script?

/ Jonas

[mikewse]

timeless wrote:
> also note that this would mean that a web site could try to knock out
> other web based mashups that it didn't like.

An "evil script" will need to locate the targeted "victim" element in order
to list/remove its event handlers. If it has the element reference there
are lots of other things it can do today, like removing the element or
popping up a glass pane in front, stealing all events.


Boris Zbarsky wrote:
> > The DOM is pretty much up for taking for any script allowed inside, so
> > are there really any new and dangerous things that can be done just
> > because event handlers are listable (and therefore removable), that
> > cannot be implemented by other means?
>
> Not if you define "event handers" narrowly as you did above; it does
> mean that some obvious uses people have had for this in the past are no
> longer possible.

Right, agreed.

> > Personally I have been missing this feature when doing client-side DOM
> > transformations, f ex transforming more simple element hierarchies
> > into widget-like experiences and wanting to move/re-register existing
> > event handlers into the new element structure. This currently requires
> > the initial structure to use DOM0 event attributes.
>
> Thank you for the use case.  Did you control all the event listeners
> involved, or did you have some way of guaranteeing that the transplanted
> listeners would still function correctly in the new location?

No, this would be an event handler function written by an unrelated party,
so it certainly wouldn't work if the event handler code f ex depended on
the child element structure. You could say that the contract for using this
DOM transformation is to not have that kind of dependencies. Also in the
current contract is not to use DOM2 events for the reasons discussed here,
but it is resulting in friction as they are at the same time being told to use
their fav Ajax lib's event connect features for a number of other reasons.


Jonas Sicking wrote:
> Also, would your example work even if the API only enumerated
> page-added event listeners, and not listeners added by the
> implementation or user script?

Sorry Jonas, I'm not 100% sure on the terminology with "implementation
and user script", but if you with user scripts are referring to external script
files included by the current page (<script src=...>) then, yes, event
handlers added from these scripts would need to be included in the handler
listing as well.
If my answer is not sufficient, could you maybe give me an example of
the kinds of scripts you were thinking about?


Best regards
Mike Wilson

[Patrick Garies]

mikewse wrote:
>  Sorry Jonas, I'm not 100% sure on the terminology with
>  "implementation and user script", but if you with user scripts are
>  referring to external script files included by the current page
>  (<script src=...>) then, yes, event handlers added from these scripts
>  would need to be included in the handler listing as well. If my
>  answer is not sufficient, could you maybe give me an example of the
>  kinds of scripts you were thinking about?

Presumably, user scripts are like those of the Greasemonkey extension
for Mozilla Firefox.

— Patrick Garies

[mikewse]

Patrick Garies wrote:

> mikewse wrote:
> >  Sorry Jonas, I'm not 100% sure on the terminology with
> >  "implementation and user script", but if you with user scripts are
> >  referring to external script files included by the current page
> >  (<script src=...>) then, yes, event handlers added from
> these scripts
> >  would need to be included in the handler listing as well. If my
> >  answer is not sufficient, could you maybe give me an example of the
> >  kinds of scripts you were thinking about?
>
> Presumably, user scripts are like those of the Greasemonkey extension
> for Mozilla Firefox.

Yes, that crossed my mind as well, but then I got unsure whether
that kind of scripts are defined and have a meaning in the
"w3c world".

Best regards
Mike Wilson

[Philippe Le Hegaret]

On Thu, 2009-04-30 at 12:06 +0200, Mike Wilson wrote:

> Patrick Garies wrote:
> > mikewse wrote:
> > >  Sorry Jonas, I'm not 100% sure on the terminology with
> > >  "implementation and user script", but if you with user scripts are
> > >  referring to external script files included by the current page
> > >  (<script src=...>) then, yes, event handlers added from
> > these scripts
> > >  would need to be included in the handler listing as well. If my
> > >  answer is not sufficient, could you maybe give me an example of the
> > >  kinds of scripts you were thinking about?
> >
> > Presumably, user scripts are like those of the Greasemonkey extension
> > for Mozilla Firefox.
>
> Yes, that crossed my mind as well, but then I got unsure whether
> that kind of scripts are defined and have a meaning in the
> "w3c world".

I don't think there is a need to put a meaning to them. Those scripts
are post document load out-of-band scripts. I didn't look deep into them
but I imagine that they are triggered by the document load event. The
DOM specifications (almost) always assumed that there could be more than
one thread at a time manipulating the DOM tree that are ignorant of each
other.

Philippe

[Jonas Sicking-2]

> Jonas Sicking wrote:
>> Also, would your example work even if the API only enumerated
>> page-added event listeners, and not listeners added by the
>> implementation or user script?
>
> Sorry Jonas, I'm not 100% sure on the terminology with "implementation
> and user script", but if you with user scripts are referring to external
> script
> files included by the current page (<script src=...>) then, yes, event
> handlers added from these scripts would need to be included in the handler
> listing as well.
> If my answer is not sufficient, could you maybe give me an example of
> the kinds of scripts you were thinking about?

With implementation listeners I mean listeners that the UA adds to the
DOM using normal DOM APIs. For example a UA might use a pair of
mouseover/mouseout listeners to display the url for a <a> link in the
statusbar. Or it can use a click listener to temporarily disable the
popup blocker.

With user scripts I mean things like grease monkey scripts that adds listeners.


Note that putting a glass pane in front of a link is unlikely to be a
useful "defense" for the page. Especially in the case of click
listeners since that would mean that the link can't be clicked at all
and so is useless. And similarly, removing the element and replacing
it with a new one is likely also a useless defense since the UA or
greasemonkey script can use for example mutation event listeners to
detect when the new element is inserted and add a listener to that
element.

/ Jonas

[mikewse]

Jonas Sicking wrote:

> > Jonas Sicking wrote:
> >> Also, would your example work even if the API only enumerated
> >> page-added event listeners, and not listeners added by the
> >> implementation or user script?
> >
> Mike Wilson wrote:
> > Sorry Jonas, I'm not 100% sure on the terminology with
> > "implementation and user script", but if you with user scripts
> > are referring to external script files included by the current
> > page (<script src=...>) then, yes, event handlers added from
> > these scripts would need to be included in the handler
> > listing as well.
> > If my answer is not sufficient, could you maybe give me an
> > example of the kinds of scripts you were thinking about?
>
> With implementation listeners I mean listeners that the UA adds to the
> DOM using normal DOM APIs. For example a UA might use a pair of
> mouseover/mouseout listeners to display the url for a <a> link in the
> statusbar. Or it can use a click listener to temporarily disable the
> popup blocker.
>
> With user scripts I mean things like grease monkey scripts
> that adds listeners.

Thanks for the clarification Jonas.

My expectation as a page author would be not to see any trace of
implementation listeners. My page didn't create these listeners so
it shouldn't list (or at all bother about) them either. My logical
view of this is that the UA uses an internal API that creates a
certain "category" of handlers that are only accessible by the UA.

User scripts are harder for me to have a well-founded opinion about
as I am not aware of their execution model. The little I have used
GreaseMonkey has given me the impression that they behave like
forcing extra script includes inside your page and from there behave
like any code delivered with the page.
Basically I would like things to work in an analogous way as for
implementation listeners, i e user script event handlers should only
be visible to user scripts and not to page scripts, but I am not
sure on how feasible that is wrt how GreaseMonkey is implemented
today.

So, having said this, what's your view on how these rules (or
variations of them) would affect the possibility of going forward
and specify event handler enumerability in DOM3?

> Note that putting a glass pane in front of a link is unlikely to be a
> useful "defense" for the page. Especially in the case of click
> listeners since that would mean that the link can't be clicked at all
> and so is useless. And similarly, removing the element and replacing
> it with a new one is likely also a useless defense since the UA or
> greasemonkey script can use for example mutation event listeners to
> detect when the new element is inserted and add a listener to that
> element.

I think you may have misunderstood why I mentioned glass pane etc (but
please excuse if I am misunderstanding you now). I was replying to a
post that said enumerability of handlers would be a security problem
in mashups, as portlets could remove or change each other's event
handlers. I made a few examples on how they may already attack each
other with existing APIs.

Best regards
Mike

[Jonas Sicking-2]

On Fri, May 1, 2009 at 6:00 AM, Mike Wilson <mikewse@...> wrote:

> Jonas Sicking wrote:
>> > Jonas Sicking wrote:
>> >> Also, would your example work even if the API only enumerated
>> >> page-added event listeners, and not listeners added by the
>> >> implementation or user script?
>> >
>> Mike Wilson wrote:
>> > Sorry Jonas, I'm not 100% sure on the terminology with
>> > "implementation and user script", but if you with user scripts
>> > are referring to external script files included by the current
>> > page (<script src=...>) then, yes, event handlers added from
>> > these scripts would need to be included in the handler
>> > listing as well.
>> > If my answer is not sufficient, could you maybe give me an
>> > example of the kinds of scripts you were thinking about?
>>
>> With implementation listeners I mean listeners that the UA adds to the
>> DOM using normal DOM APIs. For example a UA might use a pair of
>> mouseover/mouseout listeners to display the url for a <a> link in the
>> statusbar. Or it can use a click listener to temporarily disable the
>> popup blocker.
>>
>> With user scripts I mean things like grease monkey scripts
>> that adds listeners.
>
> Thanks for the clarification Jonas.
>
> My expectation as a page author would be not to see any trace of
> implementation listeners. My page didn't create these listeners so
> it shouldn't list (or at all bother about) them either. My logical
> view of this is that the UA uses an internal API that creates a
> certain "category" of handlers that are only accessible by the UA.
>
> User scripts are harder for me to have a well-founded opinion about
> as I am not aware of their execution model. The little I have used
> GreaseMonkey has given me the impression that they behave like
> forcing extra script includes inside your page and from there behave
> like any code delivered with the page.
> Basically I would like things to work in an analogous way as for
> implementation listeners, i e user script event handlers should only
> be visible to user scripts and not to page scripts, but I am not
> sure on how feasible that is wrt how GreaseMonkey is implemented
> today.

I don't think that greasemonkey handlers should be exposed since I
think that risks resulting in pages trying to fight off greasemonkey
users. We have seen this in the past where pages try to detect
greasemonkey and then block access to users that are running
greasemonkey.

What you are suggesting might be implementable, but see more below.

> So, having said this, what's your view on how these rules (or
> variations of them) would affect the possibility of going forward
> and specify event handler enumerability in DOM3?

I'm still very unconvinced of the need for enumerability. I can sort
of see the use case you are describing, but I do think the cost in
implementation complexity is fairly high since the UA will need to
keep track of several different types of event listeners. Further, the
use case you are describing would not be entirely solved by the
ability to enumerate listeners. As Boris points out, there's no
guarentees that the listeners will work when moved to another DOM
node.

Also, adding enumerability doesn't add any new capabilities. It would
strictly be a convenience function. This since the page can always
keep track of any listeners that it adds if it so desires.

/ Jonas

[mikewse]

Jonas Sicking wrote:

> On Fri, May 1, 2009 at 6:00 AM, Mike Wilson
> <mikewse@...> wrote:
> > i e user script event handlers should only
> > be visible to user scripts and not to page scripts, but I am not
> > sure on how feasible that is wrt how GreaseMonkey is implemented
> > today.
>
> I don't think that greasemonkey handlers should be exposed since I
> think that risks resulting in pages trying to fight off greasemonkey
> users. We have seen this in the past where pages try to detect
> greasemonkey and then block access to users that are running
> greasemonkey.

Fine, then we agree here.
(I guess that pages could still try to detect Greasemonkey by
inspecting element and attribute changes.)

> > So, having said this, what's your view on how these rules (or
> > variations of them) would affect the possibility of going forward
> > and specify event handler enumerability in DOM3?
>
> I'm still very unconvinced of the need for enumerability. I can sort
> of see the use case you are describing, but I do think the cost in
> implementation complexity is fairly high since the UA will need to
> keep track of several different types of event listeners.

Right, separation of event handlers into different lists or
implementing support for "shadow nodes" that represent different
views of nodes, would be needed. These are all fairly common
patterns but I have of course no idea on the implications for UA
makers, and I will trust your experience here.

> Further, the
> use case you are describing would not be entirely solved by the
> ability to enumerate listeners. As Boris points out, there's no
> guarentees that the listeners will work when moved to another DOM
> node.

I have several years experience of providing exactly this
functionality (based on DOM0 event handlers only of course) and this
has never been considered a problem. Page authors understand that
a library can't rewrite their code to do "what they mean", and thus
design their event handlers whose elements will be subject to
transformation accordingly. The one issue that keeps coming up
regularly is that DOM2 event handlers are not preserved.

Also, some of the scenarios are more about making multiple copies
and change structure just a little or not at all (with the latter
alternative being quite similar to cloneNode). In these cases
event handlers have access to the expected element structure,
assuming they start their navigation from |this| and not through
hard-wired references or similar, of course.

> Also, adding enumerability doesn't add any new capabilities. It would
> strictly be a convenience function. This since the page can always
> keep track of any listeners that it adds if it so desires.

I agree it is technically possible but I consider this a non-solution.
Personally, I wouldn't want the bloat resulting from every JavaScript
library hooking in to event listener registration and saving its own
duplicate copies of every registered handler on the page. I certainly
wouldn't have page authors using my DOM transformation routines have
to register this kind of page-wide hook.

Just to throw round some alternatives I'd say that my scenario with
client-side DOM transformations could be supported by the DOM in a
couple of different ways:

1) Allow enumeration of existing event handlers. (preferred)

2) Provide API to copy all event handlers from one node to another.
   (this still doesn't need to expose the individual event handlers)

3) And, just for the sake of it, a combination of:
   - allow cloneNode() to copy all event handlers
   - allow change of element type (tagName) on existing element
   (by far ugliest solution)

Best regards
Mike

[mikewse]

Thanks to Jonas for helping out in clarifying important
parts here. Asking those of you that have taken part in the
discussion of this action previously; what is your opinion
at this point, and are there any other parts that you want
clarified?

Best regards
Mike Wilson

Mike Wilson wrote:

> Jonas Sicking wrote:
> > On Fri, May 1, 2009 at 6:00 AM, Mike Wilson
> > <mikewse@...> wrote:
> > > i e user script event handlers should only
> > > be visible to user scripts and not to page scripts, but I am not
> > > sure on how feasible that is wrt how GreaseMonkey is implemented
> > > today.
> >
> > I don't think that greasemonkey handlers should be exposed since I
> > think that risks resulting in pages trying to fight off greasemonkey
> > users. We have seen this in the past where pages try to detect
> > greasemonkey and then block access to users that are running
> > greasemonkey.
>
> Fine, then we agree here.
> (I guess that pages could still try to detect Greasemonkey by
> inspecting element and attribute changes.)
>
> > > So, having said this, what's your view on how these rules (or
> > > variations of them) would affect the possibility of going forward
> > > and specify event handler enumerability in DOM3?
> >
> > I'm still very unconvinced of the need for enumerability. I can sort
> > of see the use case you are describing, but I do think the cost in
> > implementation complexity is fairly high since the UA will need to
> > keep track of several different types of event listeners.
>
> Right, separation of event handlers into different lists or
> implementing support for "shadow nodes" that represent different
> views of nodes, would be needed. These are all fairly common
> patterns but I have of course no idea on the implications for UA
> makers, and I will trust your experience here.
>
> > Further, the
> > use case you are describing would not be entirely solved by the
> > ability to enumerate listeners. As Boris points out, there's no
> > guarentees that the listeners will work when moved to another DOM
> > node.
>
> I have several years experience of providing exactly this
> functionality (based on DOM0 event handlers only of course) and this
> has never been considered a problem. Page authors understand that
> a library can't rewrite their code to do "what they mean", and thus
> design their event handlers whose elements will be subject to
> transformation accordingly. The one issue that keeps coming up
> regularly is that DOM2 event handlers are not preserved.
>
> Also, some of the scenarios are more about making multiple copies
> and change structure just a little or not at all (with the latter
> alternative being quite similar to cloneNode). In these cases
> event handlers have access to the expected element structure,
> assuming they start their navigation from |this| and not through
> hard-wired references or similar, of course.
>
> > Also, adding enumerability doesn't add any new
> capabilities. It would
> > strictly be a convenience function. This since the page can always
> > keep track of any listeners that it adds if it so desires.
>
> I agree it is technically possible but I consider this a non-solution.
> Personally, I wouldn't want the bloat resulting from every JavaScript
> library hooking in to event listener registration and saving its own
> duplicate copies of every registered handler on the page. I certainly
> wouldn't have page authors using my DOM transformation routines have
> to register this kind of page-wide hook.
>
> Just to throw round some alternatives I'd say that my scenario with
> client-side DOM transformations could be supported by the DOM in a
> couple of different ways:
>
> 1) Allow enumeration of existing event handlers. (preferred)
>
> 2) Provide API to copy all event handlers from one node to another.
>    (this still doesn't need to expose the individual event handlers)
>
> 3) And, just for the sake of it, a combination of:
>    - allow cloneNode() to copy all event handlers
>    - allow change of element type (tagName) on existing element
>    (by far ugliest solution)
>
> Best regards
> Mike
>
>
>