W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2009

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

From: Mike Wilson <mikewse@hotmail.com>
Date: Mon, 4 May 2009 13:09:25 +0200
Message-ID: <BAY116-DAV53C474B62396C020C9074A4680@phx.gbl>
To: "'Jonas Sicking'" <jonas@sicking.cc>
Cc: <www-dom@w3.org>
Message-ID: <005c01c9cca8$c8f10320$0201a8c0@mikedeskxp>
Jonas Sicking wrote:
> On Fri, May 1, 2009 at 6:00 AM, Mike Wilson 
> <mikewse@hotmail.com> 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
Received on Monday, 4 May 2009 11:10:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:00 GMT