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

Ryosuke Niwa 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 mailing list