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

On 15 Oct 2013 at 01:18, Glenn Maynard <glenn@zewt.org> wrote: 

> On Thu, Oct 10, 2013 at 1:41 PM, Ian Hickson <ian@hixie.ch> wrote:

[snip]

>>    document.getElementById(id)
>>
>> ...becomes:
>>
>>    document.querySelector('#' + escapeCSSIdent(id))
>>
>> ...which is a lot less pretty and understandable, especially when you
>> consider that many authors are actually coming from:
>>
>>    document.all[id]
>>
>> ...which is briefer than either, and still self-explanatory.
>>
>>
>> I feel this is a case where we're not putting authors first, but are
>> instead putting spec purity first.

> (Nothing about this discussion relates to "spec purity", whatever that
> means.  My argument is that this function is useless legacy, and that
> proliferating it to DocumentFragment seems to be for consistency's sake
> only.)

It's not useless legacy, it's a simple API call that does what it says.

I have an array of table bodies, one of which I switch into the user's view by unhooking the present one from the table and appendChild-ing the one the user now wants to look at. It's irritating enough that to search one of these tBodies for an id I have to temporarily hook it to a DocumentFragment without then being forced to use an opaque API call to get the result I want.

Personally I'd vote for it being possible to search any object for an id, never mind it having to be part of the DOM or attached to a fragment. How about:

    tbodyPtr.getElementById (id);

That might be too radical so I'd settle for getElementById and friends being available on fragments. Then we'd have consistency.

See, at the moment I've no idea whether getElementById is faster or slower than querySelector or whether it doesn't matter. But with 10,000 ids in some of my tBodies I'm thinking about it.



--
Cheers  --  Tim