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

[Alexandre Morgaut]

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:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Apr/0000.html

This turned out, as Kyle Huey mentioned it, to even be defined in HTML5:
http://www.whatwg.org/specs/web-apps/current-work/#dom-window-nameditem

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'];

Regards,

Alexandre


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

> On Sat, Jun 29, 2013 at 5:01 AM, Boris Zbarsky <bzbarsky at 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

4D SAS
60, rue d'Alsace
92110 Clichy
France

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