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 <[email protected]> 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 :    [email protected]
Web :      www.4D.com


Reply via email to