My (current) "biggest" question about when and how to actually use event delegation in a project is about element selection. At the moment I've set up my class so (in theory) it could accept a json object that describes various elements and, for example, if they are draggable or not. In the class I can then filter out those elements in with a loop I run my 'addDraggable' method which in turn runs my attach functions that adds mousedown/mouseup events to the element. I can also tell the class it's a file and, for example, run 'addFile' which in turn attaches a dblclick event that opens a dialog to set a name, show a preview or whatever. The html is created for the items and all is put on screen.
For the sake of nice html and of course some styling, I also add css classes to each element, but in theory I don't need those classes for the thing to work (css classes like 'draggable', 'file', etc. that in a way describe the element as well). If I would re-write part of the classes taking advantage of event delegation I would have create html first so that I can use css classes to filter out the elements needed that should receive the proper events for mousedown/mouseup/dblclick, etc. Correct? The css classes are required for filtering. So, that's the crossroad I'm on at the moment... and I wonder how other more "app" like developers would approach this. On Nov 24, 5:13 pm, Aaron Newton <[email protected]> wrote: > > You could reduce this cost by narrowing the scope of the selector: > > #parent a.tips, for example. > > if you added this selector to the document body, it would still be just as > expensive as it would be run every time you moused over anything. This is > bad: > > document.body.addEvent('mouseover:relay('#parent a.tips')', fn); > > this is the much, much better thing to do: > > $('parent').addEvent('mouseover:relay('a.tips', fn)
