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

James Greene james.m.greene at gmail.com
Fri Oct 18 11:09:08 PDT 2013


>
> 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);



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.


Sincerely,
    James Greene



On Fri, Oct 18, 2013 at 12:47 PM, Ryosuke Niwa <rniwa at apple.com> wrote:

> On Oct 18, 2013, at 5:22 AM, Tim Streater <tim at clothears.org.uk> wrote:
>
> > On 15 Oct 2013 at 01:18, Glenn Maynard <glenn at zewt.org> wrote:
> >
> >> On Thu, Oct 10, 2013 at 1:41 PM, Ian Hickson <ian at 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.
>
> I'm fine with exposing getElementById on DocumentFragment or on ShadowRoot
> because it returns exactly one element.
>
> What I'm opposed to is exposing getElementsByTagName, etc... because they
> return a live HTMLCollection.  HTMLCollection is a horrible mess, and the
> use of it should be discouraged as much as possible.
>
> - R. Niwa
>
>



More information about the whatwg mailing list