W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2013

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

From: James Greene <james.m.greene@gmail.com>
Date: Fri, 18 Oct 2013 13:09:08 -0500
Message-ID: <CALrbKZhAXzL27A8a+Sx6eBAXZNRbjvgYg86n_4ouesdFi1Xq4w@mail.gmail.com>
To: Ryosuke Niwa <rniwa@apple.com>
Cc: whatwg <whatwg@lists.whatwg.org>, Tim Streater <tim@clothears.org.uk>, Glenn Maynard <glenn@zewt.org>, Ian Hickson <ian@hixie.ch>, Boris Zbarsky <bzbarsky@mit.edu>
>
> 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@apple.com> wrote:

> On Oct 18, 2013, at 5:22 AM, Tim Streater <tim@clothears.org.uk> wrote:
>
> > 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.
>
> 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
>
>
Received on Friday, 18 October 2013 18:09:54 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:12 UTC