- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Wed, 24 Jul 2013 17:39:09 -0700
- To: Zirak A <zirak@mail.com>, Tim Streater <tim@clothears.org.uk>
- Cc: WHATWG <whatwg@lists.whatwg.org>, Glenn Maynard <glenn@zewt.org>, "Tab Atkins Jr." <jackalmage@gmail.com>
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:39:34 UTC