> The thread about benchmarks got me thinking about compilation and caching of > selectors too. It could be a big win for benchmarks where they use the same > selector in a loop 1000 times! :-)
The problem with caching is that it's unable to handle situations where the DOM changes in-between, unless there's an explicit .refreshCache() or some such. And doing this by default is hardly desirable, as it would cause a lot of common code to break. It is something that is definitely explorable "some day" - I'm just afraid that the payoff may not be worth it. > Ideally it could reduce cases like "#myid" to > nearly-getElementById speeds though. This and doing only .getElementsByTagName() are the easiest problems to tackle, they'll probably be added soon. > Having plugins for alternative selector > schemes also sounds interesting. This was discussed, originally, way back when jQuery was starting. We never really found a true need for this. Additionally, it's really easy to add in your own selector scheme, as is: Just overwrite jQuery.find() and jQuery.filter() with your custom selector syntax and you'll be good to go. --John _______________________________________________ jQuery mailing list [email protected] http://jquery.com/discuss/
