On Jun 28, 2013, at 5:32 PM, Zirak A <[email protected]> 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 <[email protected]> wrote: > On Sat, Jun 29, 2013 at 4:55 PM, Tim Streater <[email protected]> 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
