[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