| > you're kidding me right? Obviously you filter your queries to the closest node. Smart aleck doesn't suit you. Obviously, you can use standard DOM methods (e.g. gEBTN, gEBCN) with the "closest node" as well. And, assuming you mean an element node, you just bought yourself a world of hurt. jQuery and the like will use the Selectors API (e.g. QSA) when it suits them, and due to their disagreement with the specs, element nodes don't suit them. Some scripted query engines (e.g. YUI) ignore the disagreement, favoring wrong answers fast over right ones slower. When the libraries use their own query code, performance and compatibility go right down the toilet. In other words, use QSA with the document node, unless you want to relearn how queries work. > Having css3 query support in legacy browsers is awesome. Except that you don't have anything close to that (assuming you are using one of the "popular" libraries). And, even if you did, would you really want to send that crap to an iPhone? Only way to do it efficiently is to load the library inside conditional comments and use QSA for everything else. That is assuming you can find a query engine that actually works as expected in IE 6/7. >> massive speed losses from parsing
> Nobody is searching the entire dom for matching nodes. Parsing selectors is parsing selectors, regardless of how they will be used. One element or the entire DOM; it doesn't make a bit of difference. > The single biggest performance killer... far more important than tree traversal is event overhead. As long as you think long and hard before applying a new event handler (and use delegation whenever possible) you'll be fine even with those 'Frankenstein' queries hehe :P Again, event delegation is unrelated to queries. It's silly to assume you can use wasteful queries with impunity as long as you don't attach too many listeners. Oh, but wait, jQuery tangles up queries and event delegation with its "Live" feature. So you are screwed either way. :( And those "Frankenstein queries" are the exact opposite of self-documenting code (something most jQuery proponents/marketers get backwards). |