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: Sun, 10 May 2009 12:28:08 +0200
Message-ID: <BAY116-DAV711EB12642E1F19F640A7A4620@phx.gbl>
To: <www-dom@w3.org>
Message-ID: <00be01c9d15a$03224850$0a01a8c0@mikedeskxp>
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@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 Sunday, 10 May 2009 10:28:55 GMT

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