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

Jussi Kalliokoski jussi.kalliokoski at gmail.com
Wed Jul 24 22:42:50 PDT 2013


On Thu, Jul 25, 2013 at 3:39 AM, Ryosuke Niwa <rniwa at apple.com> wrote:
>
> getElementById is okay but we want to discourage authors from using
> methods like getElementsByTagName and getElementsByClassName that return
> live NodeList objects. They incur a lot of implementation cost in WebKit
> and hurts the DOM performance. e.g. whenever there is a LiveNode list
> somewhere in a document, WebKit walks up all ancestors of an inserted or
> removed element to clear their live node lists' caches.
>

Argh, I had forgotten about live NodeLists. OK, this is a reason that
resonates with me and justifies calling these methods obsolete. Too bad
these methods are so badly flawed and that it's not worth the cost to try
to fix those methods to return something other than a live NodeList. As for
getElementById(), I'm not sure how useful that is by itself.

Cheers,
Jussi


> On Jun 29, 2013, at 3:47 PM, Glenn Maynard <glenn at zewt.org> wrote:
>
> > On Sat, Jun 29, 2013 at 4:55 PM, Tim Streater <tim at clothears.org.uk>
> wrote:
> >
> >> But what I'm doing, I'm not doing for CSS purposes. I'm trying to find a
> >> particular row, by id, in order to modify the contents of cells in that
> >> row. I find it perverse to be using a style-related API call to do that.
> >>
> >
> > CSS uses selectors, not the other way around.  querySelector() has
> nothing
> > to do with styles.
>
> Indeed.  Note that querySelector implementations in WebKit and Blink
> optimize #foo, .foo, etc... so that they're equally if not faster than
> getElementsById, getElementsByClassName, etc...
>
> - R. Niwa
>
>



More information about the whatwg mailing list