- From: Michel Fortin <michel.fortin@michelf.com>
- Date: Fri, 3 Feb 2006 17:19:24 -0500
Le 2006-02-03 ? 11:37, Jim Ley a ?crit : > On 2/3/06, Michel Fortin <michel.fortin at michelf.com> wrote: >> Le 2006-02-03 ? 09:30, Jim Ley a ?crit : >> So to generalize the use case, when I want to attach an event to a >> child element or an element linked by any other mean to the element >> having that class, I can't use addEventListenerToClass. > > So this shows that addEventListenerToCSSSelector is really what you > want so you can attach it to A's that are children of the class > doesn't it? Not in the case of my last mail: 'A' elements can be everywhere on the page (in this specific example, they are in some sort of table of contents at the top). I would still need getElementsByClassNames to first get the div elements. Then, for each of these div elements I'd have to use addEventListenerToCSSSelector with rule "a[href='#{div id}']", where {div id} is replaced by the id attribute of the div. If I really wanted to, I could have been listening for new DOM elements of class "pane" and, for each of them, add an event handler to the corresponding A elements. Anyway, I just wanted to show one valid use for a getElementsByClassNames function and (maybe) for more advanced functions (like those with CSS selectors). All these functions would accomplish however can already be achieved by looping over the elements, so it's not like they are absolutely necessary. And you would need something a lot more powerful to handle my complex case with only one function call (maybe addEventListenerToXPath?) which I'm not asking for because it's probably overkill almost all of the time. Obviously a line has to be drawn somewhere. Michel Fortin michel.fortin at michelf.com http://www.michelf.com/
Received on Friday, 3 February 2006 14:19:24 UTC