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

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 UTC