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

[Ryosuke Niwa]

On Oct 18, 2013, at 1:50 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Fri, 18 Oct 2013, Tab Atkins Jr. wrote:
>> On Fri, Oct 18, 2013 at 11:09 AM, James Greene <james.m.greene at gmail.com> wrote:
>>> I would also love to see `getElementById` added to the 
>>> HTMLElement/Element interface. It would be nice to capitalize on that 
>>> potential perf boost in jQuery as well.
>> 
>> There's no perf boost available for searching by id on an arbitrary 
>> element.  The reason you may get a better perf for the normal functions 
>> is that documents cache a map from id->element on themselves, so you 
>> just have to do a fast hash-lookup.  Arbitrary elements don't have this 
>> map (it would be way too much memory cost), so it'll fall back to a 
>> standard tree search, exactly as a querySelector would.
> 
> Well, you _could_ just use the element's document's hash lookup, then walk 
> up the tree from the matching node to see if you reach the element, and 
> only if you don't, then fall back on walking the tree. Assuming most such 
> calls are not failing, that would give you pretty good performance (O(N) 
> on the depth of the subtree, more or less).

That's more or less what WebKit does.  The only situation under which WebKit has to traverse the entire subtree is when there are multiple elements with the same id.  In fact, the name getter access on HTMLCollection cannot always be O(n) or worse for compatibility reasons so I would be surprised if any major browser didn't have a similar optimization implemented one way or another.  Having said that, this is all implementation detail/dependent so I wouldn't focus too much on this arguing one way or another.

Regardless, I'm supportive of adding getElementById on Element as long as we don't expose getElementsBy* functions.

- R. Niwa