Except you have no reliable to way to know when you can and when you can't (and no good way to swap between libraries). Best you can do is conditional comments to target old IE versions and you sure don't want jQuery on that team.
Not exactly correct. It uses QSA only under certain conditions. Unfortunately, the fallback code is not compatible with QSA (and not consistent across their "supported" browsers).
Right and you have to test at least one browser that ranks below your expectations, else you wouldn't know if your feature detection/testing was working.
Granted, the typical Web developer will simply announce they don't care about any browsers deemed inferior (or unknown to them) at the time. History has shown that such carelessness leads to sites that are more likely to break in future (unknown to them at the time of development) browsers.
Often the expected outcome for IE 5 is a static page.
> 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).