W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2013

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

From: Alexandre Morgaut <Alexandre.Morgaut@4d.com>
Date: Mon, 1 Jul 2013 10:20:10 +0200
To: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Message-ID: <5E93FB20-E61A-4C8A-9D9B-CD4D532A121E@4d.com>
Cc: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>
First, Beside the already mentioned good arguments, I'd says that even for consistency purpose those DOM "get" methods should be available on DocumentFragment.

I mean, that's easy to think about libs / frameworks / devtools, public or internal, providing methods expecting a Document as parameter coming from different frames, iframes, tabs, windows. Probability is very high that such method expect methods as getElementById() or getElementsByTagName(). It would be sad to have a new DocumentFragment Interface and not being able to use them with such existing tools.

Actually all this make me bring back a previous discussion about IDs as property names

I've been horrified in the past (an I'm still) to discover more and more User Agents binding a references to elements with an "id" or a "name" directly to the global object:

This turned out, as Kyle Huey mentioned it, to even be defined in HTML5:

Something I mentioned was:
> if  "document.getElementById()" is too long, why not coming back to the IE4 form "document.all()"
> I would be more comfortable with at least a standard namespace global property like "elements" on window than the current situation

Meaning, probably not for named Nodes, but surely for ones with an id, I'd love to be able to write:

 var fooNode = doc.elements.foo;

Even the example with "foo:bar" would still be usable as

 var fooBarNode = doc.elements['foo:bar'];



On 30 juin 2013, at 21:44, Jussi Kalliokoski wrote:

> On Sat, Jun 29, 2013 at 5:01 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>> This is actually false.  For example, getElementById("foo:bar") is just
>> querySelector("#foo\\:bar"), which is ... nonobvious.
>> It gets worse if you don't control the id that's passed in, because
>> getElementById(arg) becomes querySelector("#"+cssEscape(arg)) where
>> cssEscape is a not entirely trivial-to-write function, if you want it to
>> work reliably.
> Not only is it not completely obvious how these methods are interoperable,
> but also the readability of code involving querySelector is questionable:
> this.buttonElement = document.querySelector('#' + this.buttonId);
> this.buttonElement = document.getElementById(this.buttonId);
> Not to mention that if you have to perform transformations on the variable,
> such as .replace(/:/g, '//:'), in a lot of cases using querySelectors is
> just way less clear a way of expressing the intention than the "obsolete"
> methods that say perfectly well what you want. Query selectors are a very
> powerful tool for complicated queries, but a lot of the time you don't need
> that power and at least in those cases I'd prefer using a more expressive
> way. The getElement methods aren't going away (and I think that's a good
> thing) and I believe it's a good idea we be consistent here and make
> DocumentFragments have these methods as well. Use the right tool for the
> job.
> Cheers,
> Jussi

Alexandre Morgaut
Wakanda Community Manager

60, rue d'Alsace
92110 Clichy

Standard : +33 1 40 87 92 00
Email :    Alexandre.Morgaut@4d.com
Web :      www.4D.com

Received on Monday, 1 July 2013 08:18:05 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:03 UTC