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

[James Greene]

While I'm not familiar with the spec for DocumentFragments, I've always
consider them to be more equivalent to a detached element node than a
document node.

Keeping that interpretation in mind, adding these methods wouldn't make
sense to me personally.  Unless my understanding is completely off-base and
fragments *are* supposed to be most similar to document nodes, I'd agree
with the earlier suggestion that those who want this functionality should
just add it themselves via JS.


Sincerely,
    James Greene



On Wed, Jul 24, 2013 at 7:39 PM, Ryosuke Niwa <rniwa at apple.com> wrote:

>
> On Jun 28, 2013, at 5:32 PM, Zirak A <zirak at mail.com> wrote:
>
> > But that's a bit looking at it backwards. Selectors are supposed to be an
> > abstraction over these methods, not the other way around.
>
> No.
>
> > The point here is that document fragments are documents - so they should
> have a consistent API.
>
> No.
>
> > Adding this isn't about "backwards compatibility" or anything of the
> sort. It's
> > adding methods that people already use, because as said, not everyone
> uses
> > selectors (and not just because of browser-compat).
>
> 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.
>
> 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
>
>