- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 28 Apr 2009 17:15:04 -0700
- To: DOM public list <www-dom@w3.org>
> 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
Received on Wednesday, 29 April 2009 00:15:48 UTC