Comments on: querySelector and querySelectorAll http://webkit.org/blog/156/queryselector-and-queryselectorall/ All about WebKit development Sat, 21 Nov 2009 23:00:28 -0800 http://wordpress.org/?v=2.8.5 hourly 1 By: Covex http://webkit.org/blog/156/queryselector-and-queryselectorall/comment-page-1/#comment-24000 Covex Sat, 22 Mar 2008 15:16:15 +0000 http://webkit.org/blog/156/queryselector-and-queryselectorall/#comment-24000 About querySelectorAll return value: I think, that "length" property must not be enumerable (like in Array) to make "for (var i in result)" work the same way as "for (var i=0; i<result.length; i++)" About querySelectorAll return value:
I think, that “length” property must not be enumerable (like in Array) to make “for (var i in result)” work the same way as “for (var i=0; i<result.length; i++)”

]]> By: David Smith http://webkit.org/blog/156/queryselector-and-queryselectorall/comment-page-1/#comment-23914 David Smith Sun, 17 Feb 2008 14:10:11 +0000 http://webkit.org/blog/156/queryselector-and-queryselectorall/#comment-23914 It's more complex than that; In order to do the return-one optimization for querySelectorAll, we would need to either special-case it (i.e. pre-parse the selector enough to determine if it's an id selector alone), or make the regular CSS parser change its behavior. The former would slow down all non-id cases for querySelectorAll, the latter would break a bunch of web pages. It’s more complex than that; In order to do the return-one optimization for querySelectorAll, we would need to either special-case it (i.e. pre-parse the selector enough to determine if it’s an id selector alone), or make the regular CSS parser change its behavior. The former would slow down all non-id cases for querySelectorAll, the latter would break a bunch of web pages.

]]> By: Nicholas Shanks http://webkit.org/blog/156/queryselector-and-queryselectorall/comment-page-1/#comment-23912 Nicholas Shanks Fri, 15 Feb 2008 15:09:06 +0000 http://webkit.org/blog/156/queryselector-and-queryselectorall/#comment-23912 David, you should submit a request that the specifications be changed. Having invalid documents on the web, namely ones with multiple identical IDs, hurts browser vendors and as a consequence, web developers and users. If querySelectorAll("#someid") was required to only return one result, and all major browsers obeyed this, then web developers wouldn't be able to treat IDs as if they were classes and get away with it. David, you should submit a request that the specifications be changed. Having invalid documents on the web, namely ones with multiple identical IDs, hurts browser vendors and as a consequence, web developers and users. If querySelectorAll(”#someid”) was required to only return one result, and all major browsers obeyed this, then web developers wouldn’t be able to treat IDs as if they were classes and get away with it.

]]> By: David Smith http://webkit.org/blog/156/queryselector-and-queryselectorall/comment-page-1/#comment-23910 David Smith Mon, 11 Feb 2008 15:46:29 +0000 http://webkit.org/blog/156/queryselector-and-queryselectorall/#comment-23910 Unfortunately, my understanding of the spec indicates that despite the invalidity of multiple elements having the same id, we're required to return all elements with a given id. That one blemish on the benchmark has been annoying me as well, but I see no way around it at the moment. :( Unfortunately, my understanding of the spec indicates that despite the invalidity of multiple elements having the same id, we’re required to return all elements with a given id. That one blemish on the benchmark has been annoying me as well, but I see no way around it at the moment. :(

]]> By: solidgoldpig http://webkit.org/blog/156/queryselector-and-queryselectorall/comment-page-1/#comment-23909 solidgoldpig Mon, 11 Feb 2008 14:25:51 +0000 http://webkit.org/blog/156/queryselector-and-queryselectorall/#comment-23909 Obviously this is excellent news, made doubly so by the recent completion of all the CSS3 selectors. However, I can't help but point out one strange anomaly that I noticed when running the slickspeed benchmark - namely that while the native implementation blows away the js libraries, there is *one* test where it actually limps in in third place (on my MacBook 1.83GHz Core Duo, 2GB RAM, OS X 10.4.11) Namely, #speech5 Webkit (r30123) consistently clocks in at 13ms as opposed to Ext at around 7ms and kQuery at 4ms. I note that * is the fastest test at 12ms - does that reflect the overhead required for querySelector to kick into gear? Could querySelector not be tweaked to spot when an id is being requested by the document object and switch to getElementById? Obviously this is excellent news, made doubly so by the recent completion of all the CSS3 selectors.

However, I can’t help but point out one strange anomaly that I noticed when running the slickspeed benchmark – namely that while the native implementation blows away the js libraries, there is *one* test where it actually limps in in third place (on my MacBook 1.83GHz Core Duo, 2GB RAM, OS X 10.4.11)

Namely, #speech5

Webkit (r30123) consistently clocks in at 13ms as opposed to Ext at around 7ms and kQuery at 4ms.

I note that * is the fastest test at 12ms – does that reflect the overhead required for querySelector to kick into gear? Could querySelector not be tweaked to spot when an id is being requested by the document object and switch to getElementById?

]]> By: Max_B http://webkit.org/blog/156/queryselector-and-queryselectorall/comment-page-1/#comment-23908 Max_B Sun, 10 Feb 2008 10:18:24 +0000 http://webkit.org/blog/156/queryselector-and-queryselectorall/#comment-23908 The SVN version and the Mootools one do different test sequences. Thats why the results differ so much. Anyway this Selector API is great. The SVN version and the Mootools one do different test sequences. Thats why the results differ so much. Anyway this Selector API is great.

]]> By: David Smith http://webkit.org/blog/156/queryselector-and-queryselectorall/comment-page-1/#comment-23907 David Smith Sat, 09 Feb 2008 01:01:30 +0000 http://webkit.org/blog/156/queryselector-and-queryselectorall/#comment-23907 dtetto: the benchmark, as checked out of svn, doesn't have any libraries included. I just grabbed the first three I thought of. dtetto: the benchmark, as checked out of svn, doesn’t have any libraries included. I just grabbed the first three I thought of.

]]> By: dtetto http://webkit.org/blog/156/queryselector-and-queryselectorall/comment-page-1/#comment-23905 dtetto Fri, 08 Feb 2008 20:38:01 +0000 http://webkit.org/blog/156/queryselector-and-queryselectorall/#comment-23905 Super awesome. Can't wait to start using this (and I really hope it's implemented into jQuery, my library of choice, soon). Random question about the benchmark page: Why remove mootools? Just because ext is more popular and there was no room for a fifth column? As I said, I'm a jQuery man myself but it seems weird that mootools (the creators of the test, after all) didn't make the cut to be included in the benchmarks. Super awesome. Can’t wait to start using this (and I really hope it’s implemented into jQuery, my library of choice, soon).

Random question about the benchmark page: Why remove mootools? Just because ext is more popular and there was no room for a fifth column? As I said, I’m a jQuery man myself but it seems weird that mootools (the creators of the test, after all) didn’t make the cut to be included in the benchmarks.

]]> By: Nicholas C. Zakas http://webkit.org/blog/156/queryselector-and-queryselectorall/comment-page-1/#comment-23904 Nicholas C. Zakas Fri, 08 Feb 2008 20:05:58 +0000 http://webkit.org/blog/156/queryselector-and-queryselectorall/#comment-23904 This is excellent news. What version of WebKit begins supporting this? It would be helpful when features like this are introduced to also include the build number and WebKit version so we can be sure to play with the right version. This is excellent news. What version of WebKit begins supporting this? It would be helpful when features like this are introduced to also include the build number and WebKit version so we can be sure to play with the right version.

]]> By: Scott Hughes http://webkit.org/blog/156/queryselector-and-queryselectorall/comment-page-1/#comment-23903 Scott Hughes Fri, 08 Feb 2008 19:04:45 +0000 http://webkit.org/blog/156/queryselector-and-queryselectorall/#comment-23903 I just realised that support for the :hover pseudo-class is mostly useless. The example given, document.querySelector(":hover"), will always return the root element (or null), whereas the example was intended to return the element directly beneath the cursor (in other words, event.target if a "click" event was triggered). But it's impossible to (reliably) discover this element because event.target is not necessarily the last element in the document.querySelectorAll(":hover") NodeList. I just realised that support for the :hover pseudo-class is mostly useless. The example given, document.querySelector(”:hover”), will always return the root element (or null), whereas the example was intended to return the element directly beneath the cursor (in other words, event.target if a “click” event was triggered). But it’s impossible to (reliably) discover this element because event.target is not necessarily the last element in the document.querySelectorAll(”:hover”) NodeList.

]]>