- From: James Greene <james.m.greene@gmail.com>
- Date: Wed, 24 Jul 2013 19:51:57 -0500
- To: Ryosuke Niwa <rniwa@apple.com>
- Cc: WHATWG <whatwg@lists.whatwg.org>, Tim Streater <tim@clothears.org.uk>, Glenn Maynard <glenn@zewt.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, Zirak A <zirak@mail.com>
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@apple.com> wrote: > > On Jun 28, 2013, at 5:32 PM, Zirak A <zirak@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@zewt.org> wrote: > > > On Sat, Jun 29, 2013 at 4:55 PM, Tim Streater <tim@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 > >
Received on Thursday, 25 July 2013 00:52:41 UTC