> you're kidding me right? Obviously you filter your queries to the closest node.
You again. Smart-ass 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.
When they 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.
> 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.
And yeah, those "Frankenstein queries" are the exact opposite of self-documenting code (something jQuery proponents get backwards).
That's completely contrary to what I've experienced. Only browsers that "need" a little extra JS/CSS are the old IE versions. Quotes indicate you don't necessarily need to enhance pages in those browsers at all these days.
If your experiences indicate otherwise, you are simply doing something wrong.
PS. jQuery is horrible. Every time you think you've figured out all of their undocumented quirks, they change the logic. It's famously inept in IE 6/7.
You again. Smart-ass 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.
When they 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.
> 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.
And yeah, those "Frankenstein queries" are the exact opposite of self-documenting code (something jQuery proponents get backwards).