[whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
rniwa at apple.com
Wed Jul 24 17:39:09 PDT 2013
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.
> The point here is that document fragments are documents - so they should have a consistent API.
> 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
More information about the whatwg