[whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments

Boris Zbarsky bzbarsky at MIT.EDU
Wed Jul 3 07:50:28 PDT 2013


On 7/3/13 3:58 AM, Mikko Rantalainen wrote:
> Boris Zbarsky, 2013-06-29 05:02 (Europe/Helsinki):
>> On 6/28/13 6:51 PM, Tab Atkins Jr. wrote:
>>> querySelector is simply a more powerful querying function than the old
>>> DOM methods,
>>
>> And somewhat slower as a result, note.
>
> If that's true, I would consider that as a bug. It should be really
> simple for an UA implementation to optimize as following
>
>      querySelector("#foo") ->  getElementById("foo")

They're not equivalent in general; see my comments earlier in this 
thread.  You have to actually parse the argument to querySelector with 
something like a selector parser to see whether you can make this 
optimization.  Note that UAs already do this at that point, but there is 
still more work than getElementById.

>      querySelectorAll("foo") -> getElementsByTagName("foo")

Those are also not equivalent.  Much more so than the other, to the 
point where optimizing this sanely is much harder.  The thing on the 
right selects on the qualified name while the thing on the left selects 
on the localName.  And they return different kinds of objects, too.  So 
something like this:

   getElementsByTagName("foo")[1]

can be way faster than querySelectorAll("foo")[1], because the latter 
has to walk the entire DOM while the former only has to walk to the 
second <foo>.

> Or, were you really talking about the difference between having to scan
> the string given as a parameter to see if it looked like "simple"
> selector that matches the old DOM method implementation?

For the #foo case, this is exactly right.

> I'd *guess* that that difference is meaningless compared to
> walking the element tree or even doing hash lookup for the id

You'd guess wrong, and I've got profiles to prove it.  ;)

-Boris



More information about the whatwg mailing list