Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 11/4/13 6:25 AM, Anne van Kesteren wrote: We should add it to DocumentFragment I think. That will be useful for ShadowRoot too. OK, agreed. Landed this for DocumentFragment in Gecko. -Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Sat, Nov 2, 2013 at 1:59 AM, Boris Zbarsky wrote: > I can obviously adjust our in-tree tests, but this test was part of jQuery's > regression test suite, and I would be slightly surprised if there's no one > out there using jQuery 1.2.6 (or later, up until the code went away; I did > check that jQuery 1.10.2 no longer has the code cited above) and if they > don't run into this issue. :( > > Anyone think otherwise? So per Kenny anyone using jQuery and not having upgraded after 2008 would per http://blog.jquery.com/2009/01/14/jquery-1-3-released/ potentially hit this problem. That does indeed seem like a compatibility problem. Can we have telemetry to confirm our suspicions? We should add it to DocumentFragment I think. That will be useful for ShadowRoot too. -- http://annevankesteren.nl/
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
(2013/11/02 9:59), Boris Zbarsky wrote: > I can obviously adjust our in-tree tests, but this test was part of > jQuery's regression test suite, and I would be slightly surprised if > there's no one out there using jQuery 1.2.6 (or later, up until the code > went away; I did check that jQuery 1.10.2 no longer has the code cited > above) and if they don't run into this issue. :( Not that I am very familar with jQuery's history, but the cited code seems to be pre-Sizzle selector implemention[1], and therefore 1.2.6 should be the last jQuery version with this bug. I assume Mozilla testsuite means that getElementById on elements are roughly compatibile with jQuery 1.3+ even if they are actually using those[2]. That's pretty lucky, I think :) It would still be a good idea to run the lastest tests in Sizzle with jQuery 1.3 with the getElementById on elements impmentation to see if there's breakage, but my guess is no. [1] The exact change seems to be this one https://github.com/jquery/jquery/commit/c85243dfc4b09e6bb87532f2025f686b6ae45a22 [2] https://github.com/jquery/jquery/blob/1.3/src/selector.js#L343 Cheers, Kenny -- Web Specialist, Opera Sphinx Game Force, Oupeng Browser, Beijing Try Oupeng: http://www.oupeng.com/
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 11/1/13 9:59 PM, Boris Zbarsky wrote: We can't have nice things. :( Though nothing I know of so far is stopping us from adding getElementById on DocumentFragment... for what that's worth. -Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 10/31/13 7:42 AM, Anne van Kesteren wrote:
On Wed, Oct 23, 2013 at 4:47 AM, Boris Zbarsky wrote:
On 10/22/13 7:00 AM, Anne van Kesteren wrote:
So do you think we should add getElementById() to ParentNode in DOM?
I actually do, yes.
http://dom.spec.whatwg.org/#parentnode
We can't have nice things. :(
When I tried to check this in, our automated tests failed while running
the regression tests for jQuery 1.2.6. This library has code like so:
var elem = ret[ret.length-1];
// Try to do a global search by ID, where we can
if ( m[1] == "#" && elem && elem.getElementById &&
!jQuery.isXMLDoc(elem) ) {
// Optimization for HTML document case
var oid = elem.getElementById(m[2]);
// etc
} else {
// walk the kids of elem
}
so if you have this markup:
alert($("div #x").length);
you end up with "ret" being the list of divs in the code above. Then if
the last div has a getElementById function that gets called and in this
case returns null, so 0 is alerted. If it doesn't, then it walks the
kids and finds the span, so 1 is alerted.
I can obviously adjust our in-tree tests, but this test was part of
jQuery's regression test suite, and I would be slightly surprised if
there's no one out there using jQuery 1.2.6 (or later, up until the code
went away; I did check that jQuery 1.10.2 no longer has the code cited
above) and if they don't run into this issue. :(
Anyone think otherwise?
-Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 10/31/13 7:42 AM, Anne van Kesteren wrote:
http://dom.spec.whatwg.org/#parentnode
Thank you.
By the way, I noticed another behavior difference between getElementById
and querySelector while implementing this. Consider this testcase:
data:text/html,alert(document.querySelector("%23foo") +
" | " + document.getElementById("foo"))
Yes, quirks mode, yadda yadda... ;)
-Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Thursday, October 31, 2013 at 5:07 PM, Bjoern Hoehrmann wrote: > * Boris Zbarsky wrote: > > If the goal is to get browsers to implement, how is it more valuable? > > Browser vendors ignore W3C test suites to an even greater extent than > > they ignore bug reports. In particular, I don't believe browser vendors > > typically run W3C test suites en masse regularly, whereas they do > > regularly look at the bug reports that get filed on them. > > My purpose was to lament that we currently lack the infrastructure > needed so that people interested in new features or other changes can > contribute tests for those features and changes to such suites. That > very much includes that many of the existing suites suck badly. > > That would have many benefits, for instance, it makes it easy to track > the implementation status of something across many implementations, > which is information that web developers critically need, and it helps > to identify cases where one browser is the odd one out. I would rather > people help us work on tests than helping Anne fill out web forms. Such an infrastructure is in the process of being built[1]. See the Test the Web Forward effort[2] which now regroups all of Open Web platform testing[3]. You're welcome to contribute. --tobie --- [1]: http://testthewebforward.org/blog/2013/02/20/testing-the-open-web-platform.html [2]: http://testthewebforward.org/ [3]: http://testthewebforward.org/blog/2013/10/30/welcoming-testtwf-to-w3c.html
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Thursday, October 31, 2013 at 4:27 PM, Ms2ger wrote: > On 10/31/2013 04:13 PM, Boris Zbarsky wrote: > > In particular, I don't believe browser vendors > > typically run W3C test suites en masse regularly, > > Just going to note here that James Graham is, in fact, working on doing > that for Mozilla. … and a similar effort is happening for Blink. --tobie
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
* Boris Zbarsky wrote: >If the goal is to get browsers to implement, how is it more valuable? >Browser vendors ignore W3C test suites to an even greater extent than >they ignore bug reports. In particular, I don't believe browser vendors >typically run W3C test suites en masse regularly, whereas they do >regularly look at the bug reports that get filed on them. My purpose was to lament that we currently lack the infrastructure needed so that people interested in new features or other changes can contribute tests for those features and changes to such suites. That very much includes that many of the existing suites suck badly. That would have many benefits, for instance, it makes it easy to track the implementation status of something across many implementations, which is information that web developers critically need, and it helps to identify cases where one browser is the odd one out. I would rather people help us work on tests than helping Anne fill out web forms. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 10/31/2013 04:13 PM, Boris Zbarsky wrote: In particular, I don't believe browser vendors typically run W3C test suites en masse regularly, Just going to note here that James Graham is, in fact, working on doing that for Mozilla. HTH Ms2ger
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 10/31/13 10:14 AM, Bjoern Hoehrmann wrote: What we should have is proper automated test suites that let us know what web browsers do and do not implement. We should have that too, sure. Creating rudimentary tests for the relevant cases here probably takes less effort in addition to being far more valuable than filing the bug reports. If the goal is to get browsers to implement, how is it more valuable? Browser vendors ignore W3C test suites to an even greater extent than they ignore bug reports. In particular, I don't believe browser vendors typically run W3C test suites en masse regularly, whereas they do regularly look at the bug reports that get filed on them. -Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 10/31/13 4:07 AM, Simon Pieters wrote: I meant for element.getElementsByTagName, but not for document.getElementsByTagName. Yes, I assumed that. That's why I wondered what the compat situation is instead of just claiming it's not compatible... -Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
* Anne van Kesteren wrote: >I also filed some browser bugs just in case people are not paying >attention here: > >* https://bugzilla.mozilla.org/show_bug.cgi?id=933193 >* http://code.google.com/p/chromium/issues/detail?id=313655 >* https://bugs.webkit.org/show_bug.cgi?id=123565 > >Should really have a way to file a bug on all browsers whenever >something like this comes up... What we should have is proper automated test suites that let us know what web browsers do and do not implement. Creating rudimentary tests for the relevant cases here probably takes less effort in addition to being far more valuable than filing the bug reports. I tested with http://shadowregistry.org/js/misc/#t6edb2a2b01f100f64f8f372bd3826328 and that seems to confirm my suspicion, even if we ignore that such a test can be automatically derived from the interface description. All I did was appending // SVGSVGElement.prototype.getElementById is defined return !!SVGSVGElement.prototype.getElementById; to a text file. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Thursday, October 31, 2013 at 12:42 PM, Anne van Kesteren wrote: > Should really have a way to file a bug on all browsers whenever > something like this comes up... Yes please. --tobie
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Wed, Oct 23, 2013 at 4:47 AM, Boris Zbarsky wrote: > On 10/22/13 7:00 AM, Anne van Kesteren wrote: >> So do you think we should add getElementById() to ParentNode in DOM? > > I actually do, yes. http://dom.spec.whatwg.org/#parentnode I also filed some browser bugs just in case people are not paying attention here: * https://bugzilla.mozilla.org/show_bug.cgi?id=933193 * http://code.google.com/p/chromium/issues/detail?id=313655 * https://bugs.webkit.org/show_bug.cgi?id=123565 Should really have a way to file a bug on all browsers whenever something like this comes up... -- http://annevankesteren.nl/
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Thu, 31 Oct 2013 06:48:00 +0100, Boris Zbarsky wrote: On 10/23/13 4:39 AM, Simon Pieters wrote: Or maybe we could remove the name lookup thing altogether for Element.getElementsByTagName et al? Hmm. There are some compat worries here; do we have any indications that this name lookup is unused in the wild? I meant for element.getElementsByTagName, but not for document.getElementsByTagName. I don't know what the compat situation is for document.getElementsByTagName's name lookup. -- Simon Pieters Opera Software
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 10/23/13 4:39 AM, Simon Pieters wrote: Or maybe we could remove the name lookup thing altogether for Element.getElementsByTagName et al? Hmm. There are some compat worries here; do we have any indications that this name lookup is unused in the wild? -Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Wed, 23 Oct 2013 05:45:12 +0200, Boris Zbarsky wrote: On 10/22/13 2:42 PM, Ryosuke Niwa wrote: Because of HTMLCollection's name getter, all major browsers must be capable of a id+name lookup at every element (since Element has getElementsByTagName that returns a HTMLCollection). While true, in practice pretty much no one uses the name getter on that object, so nothing right now forces browsers to implement it in a particularly efficient (as opposed to simple) way. Or maybe we could remove the name lookup thing altogether for Element.getElementsByTagName et al? -- Simon Pieters Opera Software
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 10/22/13 7:00 AM, Anne van Kesteren wrote: So do you think we should add getElementById() to ParentNode in DOM? I actually do, yes. It seems the advantages are that we can optimize it better than querySelector() because there is no selector parsing. This, in my mind, is a somewhat minor advantage. And because there is no selector parsing, you can simply pass the value of an element's id attribute rather than escaping said value using CSS escape rules. Right. More importantly, you don't have to even understand that there are CSS escaping rules involved, which is a bigger hurdle than doing the escaping once you've understood that part What it seems we lack is a clear need for either Where by "either" you mean lack of a need for passing without escaping first? See above. but if the cost of implementing it is low, maybe it's worth it? The way I see it, UAs already have to implement SVGSVGElement.prototype.getElementById. I suspect that in practice the same implementation can be used for any Element or DocumentFragment, so the cost of implementing is in fact quite low. -Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 10/22/13 2:42 PM, Ryosuke Niwa wrote: Because of HTMLCollection's name getter, all major browsers must be capable of a id+name lookup at every element (since Element has getElementsByTagName that returns a HTMLCollection). While true, in practice pretty much no one uses the name getter on that object, so nothing right now forces browsers to implement it in a particularly efficient (as opposed to simple) way. -Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Tue, Oct 22, 2013 at 7:42 PM, Ryosuke Niwa wrote: > On Oct 22, 2013, at 4:00 AM, Anne van Kesteren wrote: >> So do you think we should add getElementById() to ParentNode in DOM? > > Why not to Element? ParentNode encompasses Document, DocumentFragment, and Element. See http://dom.spec.whatwg.org/#parentnode I think features that make sense on Document and Element should also be on DocumentFragment, unless they're really not applicable for some reason. -- http://annevankesteren.nl/
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Oct 22, 2013, at 4:00 AM, Anne van Kesteren wrote: > On Fri, Oct 18, 2013 at 10:56 PM, Boris Zbarsky wrote: >> So it looks to me like in practice Element.getElementById could be quite a >> bit faster than the equivalent querySelector call, for both the in-tree case >> (where both can avoid walking the tree) and the out-of-tree case (where both >> need to walk the tree). >> >> Food for thought. > > So do you think we should add getElementById() to ParentNode in DOM? Why not to Element? > It seems the advantages are that we can optimize it better than > querySelector() because there is no selector parsing. And because > there is no selector parsing, you can simply pass the value of an > element's id attribute rather than escaping said value using CSS > escape rules. > > What it seems we lack is a clear need for either, but if the cost of > implementing it is low, maybe it's worth it? Because of HTMLCollection's name getter, all major browsers must be capable of a id+name lookup at every element (since Element has getElementsByTagName that returns a HTMLCollection). - R. Niwa
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Fri, Oct 18, 2013 at 10:56 PM, Boris Zbarsky wrote: > So it looks to me like in practice Element.getElementById could be quite a > bit faster than the equivalent querySelector call, for both the in-tree case > (where both can avoid walking the tree) and the out-of-tree case (where both > need to walk the tree). > > Food for thought. So do you think we should add getElementById() to ParentNode in DOM? It seems the advantages are that we can optimize it better than querySelector() because there is no selector parsing. And because there is no selector parsing, you can simply pass the value of an element's id attribute rather than escaping said value using CSS escape rules. What it seems we lack is a clear need for either, but if the cost of implementing it is low, maybe it's worth it? -- http://annevankesteren.nl/
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 19 Oct 2013 at 18:27, Ms2ger wrote: > Quoting part of the original email you trimmed: > >> Luckily, we have SVGSVGElement.prototype.getElementById available to >> compare to Element.prototype.querySelector. > > That is, getElementById is available on |svg| elements in the SVG namespace. Yeah, thanks, I missed the significance of that, drat it. -- Cheers -- Tim
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
Hi Tim,
On 10/19/2013 07:03 PM, Tim Streater wrote:
On 18 Oct 2013 at 22:56, Boris Zbarsky posted, inter alia,
this code:
[1] The testcase:
document.write("\n");
var node;
var count = 20;
function doTests(root, elementId, descQS, descQSNoConcat, descGEBI) {
var start = new Date;
for (var i = 0; i < count; ++i)
node = root.querySelector("#" + elementId);
var stop = new Date;
document.writeln(descQS + ((stop - start) / count * 1e6));
var start = new Date;
for (var i = 0; i < count; ++i)
node = root.querySelector("#test");
var stop = new Date;
document.writeln(descQSNoConcat + ((stop - start) / count * 1e6));
var start = new Date;
for (var i = 0; i < count; ++i)
node = root.getElementById(elementId);
var stop = new Date;
document.writeln(descGEBI + ((stop - start) / count * 1e6));
}
var root = document.getElementById("root");
var start = new Date;
for (var i = 0; i < count; ++i)
node = document.getElementById("test");
var stop = new Date;
document.writeln("document.getElementById: " + ((stop - start) /
count * 1e6));
doTests(root, "test",
"In-tree querySelector: ",
"In-tree querySelector, no string concat: ",
"In-tree getElementById: ");
root.remove();
doTests(root, "test",
"Out-of-tree querySelector: ",
"Out-of-tree querySelector, no string concat: ",
"Out-of-tree getElementById: ");
I've tested this here on five browsers and it runs to completion Ok
apart from iCab, which didn't like root.remove so I did that bit
longhand. But I'm left confused. The other day I ranted about needing
to use a document fragment and having to use querySelector on a table
body. Now this code appears to imply that I need neither and could
have used getElementById all along, since your application of
getElementById above is mostly not to a document. I'm sure that when
I tested that, a year or so back, it didn't work. Could you
elucidate?
Quoting part of the original email you trimmed:
Luckily, we have SVGSVGElement.prototype.getElementById available to
compare to Element.prototype.querySelector.
That is, getElementById is available on |svg| elements in the SVG namespace.
HTH
Ms2ger
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 18 Oct 2013 at 22:56, Boris Zbarsky posted, inter alia,
this code:
> [1] The testcase:
>
>
>
> document.write("\n");
>
>
> var node;
> var count = 20;
> function doTests(root, elementId, descQS, descQSNoConcat, descGEBI) {
> var start = new Date;
> for (var i = 0; i < count; ++i)
> node = root.querySelector("#" + elementId);
> var stop = new Date;
> document.writeln(descQS + ((stop - start) / count * 1e6));
> var start = new Date;
> for (var i = 0; i < count; ++i)
> node = root.querySelector("#test");
> var stop = new Date;
> document.writeln(descQSNoConcat + ((stop - start) / count * 1e6));
> var start = new Date;
> for (var i = 0; i < count; ++i)
> node = root.getElementById(elementId);
> var stop = new Date;
> document.writeln(descGEBI + ((stop - start) / count * 1e6));
> }
> var root = document.getElementById("root");
> var start = new Date;
> for (var i = 0; i < count; ++i)
> node = document.getElementById("test");
> var stop = new Date;
> document.writeln("document.getElementById: " + ((stop - start) /
> count * 1e6));
> doTests(root, "test",
> "In-tree querySelector: ",
> "In-tree querySelector, no string concat: ",
> "In-tree getElementById: ");
> root.remove();
> doTests(root, "test",
> "Out-of-tree querySelector: ",
> "Out-of-tree querySelector, no string concat: ",
> "Out-of-tree getElementById: ");
>
I've tested this here on five browsers and it runs to completion Ok apart from
iCab, which didn't like root.remove so I did that bit longhand. But I'm left
confused. The other day I ranted about needing to use a document fragment and
having to use querySelector on a table body. Now this code appears to imply
that I need neither and could have used getElementById all along, since your
application of getElementById above is mostly not to a document. I'm sure that
when I tested that, a year or so back, it didn't work. Could you elucidate?
Thanks,
--
Cheers -- Tim
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 10/18/13 5:56 PM, Boris Zbarsky wrote: I used a fairly large subtree that needs walking (1000 elements) Er, I _meant_ to, but the testcase clearly only has 100 elements. The numbers with 1000 elements are: Chrome: document.getElementById: 50 In-tree querySelector: 210 In-tree querySelector, no string concat: 100 In-tree getElementById: 60 Out-of-tree querySelector: 23590 Out-of-tree querySelector, no string concat: 22870 Out-of-tree getElementById: 4450 Stock Firefox: document.getElementById: 60 In-tree querySelector: 140 In-tree querySelector, no string concat: 130 In-tree getElementById: 190 Out-of-tree querySelector: 8590 Out-of-tree querySelector, no string concat: 8560 Out-of-tree getElementById: 8620 Modified Firefox: document.getElementById: 60 In-tree querySelector: 130 In-tree querySelector, no string concat: 120 In-tree getElementById: 4270 Out-of-tree querySelector: 8320 Out-of-tree querySelector, no string concat: 8300 Out-of-tree getElementById: 4210 -Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 10/18/13 3:11 PM, Tab Atkins Jr. wrote: There's no perf boost available for searching by id on an arbitrary element. The reason you may get a better perf for the normal functions is that documents cache a map from id->element on themselves, so you just have to do a fast hash-lookup. Arbitrary elements don't have this map (it would be way too much memory cost), so it'll fall back to a standard tree search, exactly as a querySelector would. Tab, you keep saying that. Let's try science instead of guessing. Performance of getting an element by ID depends on whether you have to do the following: 1) Perform string concatenation (like '#'+foo) to get the string to pas to the browser. 2) Walk an entire subtree (this can be avoided by using the id-to-element-list hash and then checking the results to see if they match, in cases when the root of the search is in the document). 3) Do complicated selector checking while walking the tree. 4) Probably other factors. Luckily, we have SVGSVGElement.prototype.getElementById available to compare to Element.prototype.querySelector. We also have at least two distinct implementations (Chrome and Firefox are the ones I tried), and luckily some of them are open-source so we can examine the impact of different implementation strategies. With that in mind, I wrote up a testcase [1] to test the cases that do and do not require a string concatenation for the querySelector call (see item 1 in list above), in and out of the document (see item 2 in list above). I used a fairly large subtree that needs walking (1000 elements), but you can modify the testcase to your heart's content. I then tested it in three implementations: Chrome (which I'm treating as a black-box for now), stock Firefox (in which SVGSVGElement.prototype.getElementById in fact calls querySelector internally, after CSS-escaping the input and whatnot) and a modified Firefox [2], in which SVGSVGElement.prototype.getElementById just does a naive tree-walk with no attempt to fast-path the in-document case. I also included document.getElementById as a control. The numbers are as follows, where all numbers are nanoseconds per call on my hardware. Note that for lower iteration counts the effects of running in slower JIT levels might also pop up; those shouldn't affect things by more than 10ns or so per loop iteration in this case, I expect. Chrome: document.getElementById: 55 In-tree querySelector: 220 In-tree querySelector, no string concat: 100 In-tree getElementById: 55 Out-of-tree querySelector: 2115 Out-of-tree querySelector, no string concat: 1995 Out-of-tree getElementById: 270 Stock Firefox: document.getElementById: 60 In-tree querySelector: 140 In-tree querySelector, no string concat: 130 In-tree getElementById: 185 Out-of-tree querySelector: 905 Out-of-tree querySelector, no string concat: 910 Out-of-tree getElementById: 975 Modified Firefox: document.getElementById: 60 In-tree querySelector: 125 In-tree querySelector, no string concat: 120 In-tree getElementById: 215 Out-of-tree querySelector: 885 Out-of-tree querySelector, no string concat: 880 Out-of-tree getElementById: 205 So it looks to me like in practice Element.getElementById could be quite a bit faster than the equivalent querySelector call, for both the in-tree case (where both can avoid walking the tree) and the out-of-tree case (where both need to walk the tree). Food for thought. -Boris [1] The testcase: document.write("\n"); var node; var count = 20; function doTests(root, elementId, descQS, descQSNoConcat, descGEBI) { var start = new Date; for (var i = 0; i < count; ++i) node = root.querySelector("#" + elementId); var stop = new Date; document.writeln(descQS + ((stop - start) / count * 1e6)); var start = new Date; for (var i = 0; i < count; ++i) node = root.querySelector("#test"); var stop = new Date; document.writeln(descQSNoConcat + ((stop - start) / count * 1e6)); var start = new Date; for (var i = 0; i < count; ++i) node = root.getElementById(elementId); var stop = new Date; document.writeln(descGEBI + ((stop - start) / count * 1e6)); } var root = document.getElementById("root"); var start = new Date; for (var i = 0; i < count; ++i) node = document.getElementById("test"); var stop = new Date;document.writeln("document.getElementById: " + ((stop - start) / count * 1e6));doTests(root, "test", "In-tree querySelector: ", "In-tree querySelector, no string concat: ", "In-tree getElementById: "); root.remove(); doTests(root, "test", "Out-of-tree querySelector: ", "Out-of-tree querySelector, no string concat: ",
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Oct 18, 2013, at 1:50 PM, Ian Hickson wrote: > On Fri, 18 Oct 2013, Tab Atkins Jr. wrote: >> On Fri, Oct 18, 2013 at 11:09 AM, James Greene >> wrote: >>> I would also love to see `getElementById` added to the >>> HTMLElement/Element interface. It would be nice to capitalize on that >>> potential perf boost in jQuery as well. >> >> There's no perf boost available for searching by id on an arbitrary >> element. The reason you may get a better perf for the normal functions >> is that documents cache a map from id->element on themselves, so you >> just have to do a fast hash-lookup. Arbitrary elements don't have this >> map (it would be way too much memory cost), so it'll fall back to a >> standard tree search, exactly as a querySelector would. > > Well, you _could_ just use the element's document's hash lookup, then walk > up the tree from the matching node to see if you reach the element, and > only if you don't, then fall back on walking the tree. Assuming most such > calls are not failing, that would give you pretty good performance (O(N) > on the depth of the subtree, more or less). That's more or less what WebKit does. The only situation under which WebKit has to traverse the entire subtree is when there are multiple elements with the same id. In fact, the name getter access on HTMLCollection cannot always be O(n) or worse for compatibility reasons so I would be surprised if any major browser didn't have a similar optimization implemented one way or another. Having said that, this is all implementation detail/dependent so I wouldn't focus too much on this arguing one way or another. Regardless, I'm supportive of adding getElementById on Element as long as we don't expose getElementsBy* functions. - R. Niwa
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Fri, 18 Oct 2013, Tab Atkins Jr. wrote: > On Fri, Oct 18, 2013 at 11:09 AM, James Greene > wrote: > > I would also love to see `getElementById` added to the > > HTMLElement/Element interface. It would be nice to capitalize on that > > potential perf boost in jQuery as well. > > There's no perf boost available for searching by id on an arbitrary > element. The reason you may get a better perf for the normal functions > is that documents cache a map from id->element on themselves, so you > just have to do a fast hash-lookup. Arbitrary elements don't have this > map (it would be way too much memory cost), so it'll fall back to a > standard tree search, exactly as a querySelector would. Well, you _could_ just use the element's document's hash lookup, then walk up the tree from the matching node to see if you reach the element, and only if you don't, then fall back on walking the tree. Assuming most such calls are not failing, that would give you pretty good performance (O(N) on the depth of the subtree, more or less). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
> > There's no perf boost available for searching by id on an arbitrary > element. The reason you may get a better perf for the normal > functions is that documents cache a map from id->element on > themselves, so you just have to do a fast hash-lookup. Arbitrary > elements don't have this map (it would be way too much memory cost), > so it'll fall back to a standard tree search, exactly as a > querySelector would. Hmm, I suppose that makes sense. Bummer. Thanks for the concise explanation! Sincerely, James Greene On Fri, Oct 18, 2013 at 2:11 PM, Tab Atkins Jr. wrote: > On Fri, Oct 18, 2013 at 11:09 AM, James Greene > wrote: > > I would also love to see `getElementById` added to the > HTMLElement/Element > > interface. It would be nice to capitalize on that potential perf boost in > > jQuery as well. > > There's no perf boost available for searching by id on an arbitrary > element. The reason you may get a better perf for the normal > functions is that documents cache a map from id->element on > themselves, so you just have to do a fast hash-lookup. Arbitrary > elements don't have this map (it would be way too much memory cost), > so it'll fall back to a standard tree search, exactly as a > querySelector would. > > ~TJ >
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Fri, Oct 18, 2013 at 11:09 AM, James Greene wrote: > I would also love to see `getElementById` added to the HTMLElement/Element > interface. It would be nice to capitalize on that potential perf boost in > jQuery as well. There's no perf boost available for searching by id on an arbitrary element. The reason you may get a better perf for the normal functions is that documents cache a map from id->element on themselves, so you just have to do a fast hash-lookup. Arbitrary elements don't have this map (it would be way too much memory cost), so it'll fall back to a standard tree search, exactly as a querySelector would. ~TJ
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
>
> Personally I'd vote for it being possible to search any object for an id,
> never mind it having to be part of the DOM or attached to a fragment. How
> about:
> tbodyPtr.getElementById (id);
I would also love to see `getElementById` added to the HTMLElement/Element
interface. It would be nice to capitalize on that potential perf boost in
jQuery as well.
Sincerely,
James Greene
On Fri, Oct 18, 2013 at 12:47 PM, Ryosuke Niwa wrote:
> On Oct 18, 2013, at 5:22 AM, Tim Streater wrote:
>
> > On 15 Oct 2013 at 01:18, Glenn Maynard wrote:
> >
> >> On Thu, Oct 10, 2013 at 1:41 PM, Ian Hickson wrote:
> >
> > [snip]
> >
> >>> document.getElementById(id)
> >>>
> >>> ...becomes:
> >>>
> >>> document.querySelector('#' + escapeCSSIdent(id))
> >>>
> >>> ...which is a lot less pretty and understandable, especially when you
> >>> consider that many authors are actually coming from:
> >>>
> >>> document.all[id]
> >>>
> >>> ...which is briefer than either, and still self-explanatory.
> >>>
> >>>
> >>> I feel this is a case where we're not putting authors first, but are
> >>> instead putting spec purity first.
> >
> >> (Nothing about this discussion relates to "spec purity", whatever that
> >> means. My argument is that this function is useless legacy, and that
> >> proliferating it to DocumentFragment seems to be for consistency's sake
> >> only.)
> >
> > It's not useless legacy, it's a simple API call that does what it says.
> >
> > I have an array of table bodies, one of which I switch into the user's
> view by unhooking the present one from the table and appendChild-ing the
> one the user now wants to look at. It's irritating enough that to search
> one of these tBodies for an id I have to temporarily hook it to a
> DocumentFragment without then being forced to use an opaque API call to get
> the result I want.
> >
> > Personally I'd vote for it being possible to search any object for an
> id, never mind it having to be part of the DOM or attached to a fragment.
> How about:
> >
> >tbodyPtr.getElementById (id);
> >
> > That might be too radical so I'd settle for getElementById and friends
> being available on fragments. Then we'd have consistency.
>
> I'm fine with exposing getElementById on DocumentFragment or on ShadowRoot
> because it returns exactly one element.
>
> What I'm opposed to is exposing getElementsByTagName, etc... because they
> return a live HTMLCollection. HTMLCollection is a horrible mess, and the
> use of it should be discouraged as much as possible.
>
> - R. Niwa
>
>
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Oct 18, 2013, at 5:22 AM, Tim Streater wrote:
> On 15 Oct 2013 at 01:18, Glenn Maynard wrote:
>
>> On Thu, Oct 10, 2013 at 1:41 PM, Ian Hickson wrote:
>
> [snip]
>
>>> document.getElementById(id)
>>>
>>> ...becomes:
>>>
>>> document.querySelector('#' + escapeCSSIdent(id))
>>>
>>> ...which is a lot less pretty and understandable, especially when you
>>> consider that many authors are actually coming from:
>>>
>>> document.all[id]
>>>
>>> ...which is briefer than either, and still self-explanatory.
>>>
>>>
>>> I feel this is a case where we're not putting authors first, but are
>>> instead putting spec purity first.
>
>> (Nothing about this discussion relates to "spec purity", whatever that
>> means. My argument is that this function is useless legacy, and that
>> proliferating it to DocumentFragment seems to be for consistency's sake
>> only.)
>
> It's not useless legacy, it's a simple API call that does what it says.
>
> I have an array of table bodies, one of which I switch into the user's view
> by unhooking the present one from the table and appendChild-ing the one the
> user now wants to look at. It's irritating enough that to search one of these
> tBodies for an id I have to temporarily hook it to a DocumentFragment without
> then being forced to use an opaque API call to get the result I want.
>
> Personally I'd vote for it being possible to search any object for an id,
> never mind it having to be part of the DOM or attached to a fragment. How
> about:
>
>tbodyPtr.getElementById (id);
>
> That might be too radical so I'd settle for getElementById and friends being
> available on fragments. Then we'd have consistency.
I'm fine with exposing getElementById on DocumentFragment or on ShadowRoot
because it returns exactly one element.
What I'm opposed to is exposing getElementsByTagName, etc... because they
return a live HTMLCollection. HTMLCollection is a horrible mess, and the use
of it should be discouraged as much as possible.
- R. Niwa
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 15 Oct 2013 at 01:18, Glenn Maynard wrote:
> On Thu, Oct 10, 2013 at 1:41 PM, Ian Hickson wrote:
[snip]
>>document.getElementById(id)
>>
>> ...becomes:
>>
>>document.querySelector('#' + escapeCSSIdent(id))
>>
>> ...which is a lot less pretty and understandable, especially when you
>> consider that many authors are actually coming from:
>>
>>document.all[id]
>>
>> ...which is briefer than either, and still self-explanatory.
>>
>>
>> I feel this is a case where we're not putting authors first, but are
>> instead putting spec purity first.
> (Nothing about this discussion relates to "spec purity", whatever that
> means. My argument is that this function is useless legacy, and that
> proliferating it to DocumentFragment seems to be for consistency's sake
> only.)
It's not useless legacy, it's a simple API call that does what it says.
I have an array of table bodies, one of which I switch into the user's view by
unhooking the present one from the table and appendChild-ing the one the user
now wants to look at. It's irritating enough that to search one of these
tBodies for an id I have to temporarily hook it to a DocumentFragment without
then being forced to use an opaque API call to get the result I want.
Personally I'd vote for it being possible to search any object for an id, never
mind it having to be part of the DOM or attached to a fragment. How about:
tbodyPtr.getElementById (id);
That might be too radical so I'd settle for getElementById and friends being
available on fragments. Then we'd have consistency.
See, at the moment I've no idea whether getElementById is faster or slower than
querySelector or whether it doesn't matter. But with 10,000 ids in some of my
tBodies I'm thinking about it.
--
Cheers -- Tim
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 10 Oct 2013, at 15:05, Simon Pieters wrote: > I've added CSS.escape(foo). > > https://dvcs.w3.org/hg/csswg/rev/09466af95185 Very useful, thanks. Here’s a polyfill for `CSS.escape`: https://github.com/mathiasbynens/CSS.escape Tests: https://github.com/mathiasbynens/CSS.escape/blob/master/tests/tests.js
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Thu, Oct 10, 2013 at 1:41 PM, Ian Hickson wrote:
> Leaving aside the issue that "CSS-escape" is more than one operation
> depending on what kind of token you're creating,
My understanding is that you can do both of them, at least for
selector-related escaping, so the author doesn't have to know about the
difference. That's based on Simon's earlier mail:
On Thu, Oct 10, 2013 at 6:06 AM, Simon Pieters wrote:
> The common case is escaping as ident. An API to escape as ident could be
> used for escaping strings, too. In order to not make people think more than
> just remembering to escape at all, it might be a good idea to just have one
> API to serve both cases, e.g. CSS.escape(foo).
>
I don't think it's actually as trivial as you think.
>
>document.getElementById(id)
>
> ...becomes:
>
>document.querySelector('#' + escapeCSSIdent(id))
>
> ...which is a lot less pretty and understandable, especially when you
> consider that many authors are actually coming from:
>
>document.all[id]
>
> ...which is briefer than either, and still self-explanatory.
>
>
> I feel this is a case where we're not putting authors first, but are
> instead putting spec purity first.
>
(Nothing about this discussion relates to "spec purity", whatever that
means. My argument is that this function is useless legacy, and that
proliferating it to DocumentFragment seems to be for consistency's sake
only.)
I think the example you gave is trivial and perfectly fine, particularly
since you need to do the same thing anyway as soon as you're doing anything
other than ID lookups or the other couple special cases. I find that
happens very quickly, so my code is a lot more readable when I just use
querySelector everywhere.
But adding another getElementById is probably low cost, so it doesn't
bother me that much.
--
Glenn Maynard
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Thu, 10 Oct 2013 17:52:49 +0200, Glenn Adams wrote: You'd actually write "CSS.escape", so that's basically the longer, different name. Is that sufficient? I don't want to bikeshed over this, but I was thinking of perhaps serializeIdent(), or escapeIdent(). The API is intended to be used for escaping CSS strings too. Also, I think most Web developers don't think in terms of CSS tokens. Serialize seems a bit wrong since the input isn't an object. -- Simon Pieters Opera Software
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Thu, Oct 10, 2013 at 10:26 PM, Scott González wrote: > I don't think there was any response to this. What is the reason for > keeping these methods off of DocumentFragment if new APIs which inherit > from DocumentFragment are going to have the methods anyway? That's not going to happen. -- http://annevankesteren.nl/
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Ian Hickson > I feel this is a case where we're not putting authors first, but are instead > putting spec purity first. In terms of not speccing getElementById etc., I see what you mean. But I do want to point out that adding CSS.escape has made a certain class of authors very happy, namely library authors. So both approaches are good ones.
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Fri, Sep 6, 2013 at 8:47 AM, Scott González wrote: > On Fri, Jun 28, 2013 at 6:51 PM, Tab Atkins Jr. wrote: > >> On Fri, Jun 28, 2013 at 2:28 PM, Zirak A wrote: >> > Besides my personal aversion towards selectors being in the DOM API, >> there's >> > also the simple fact that it makes sense for document fragments to have >> these >> > methods. >> >> That's far from obvious, given that I don't think it makes sense to >> spread those obsolete methods around any further. >> > > They were already spread to ShadowRoot. Does anyone have a reference to > that discussion that led to that decision? It seems like if they're being > added to ShadowRoot, which inherits from DocumentFragment, we might as well > just add them to DocumentFragment and be done with it. At least from a > non-implementor's view that seems to make sense. > I don't think there was any response to this. What is the reason for keeping these methods off of DocumentFragment if new APIs which inherit from DocumentFragment are going to have the methods anyway?
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Thu, Oct 10, 2013 at 8:51 PM, Boris Zbarsky wrote: > On 10/10/13 2:41 PM, Ian Hickson wrote: >> I feel this is a case where we're not putting authors first, but are >> instead putting spec purity first. > > Ah, that sums up my vague feelings of discontent here perfectly. +1000. ;) FWIW, I'm not super opposed to adding DocumentFragment.prototype.getElementById(). I was just hoping to wait with that until we had more experience with query()/queryAll(). Do we have to roll them out at the same time? -- http://annevankesteren.nl/
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 10/10/13 2:41 PM, Ian Hickson wrote: I feel this is a case where we're not putting authors first, but are instead putting spec purity first. Ah, that sums up my vague feelings of discontent here perfectly. +1000. ;) -Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Wed, 9 Oct 2013, Glenn Maynard wrote:
> On Wed, Oct 9, 2013 at 7:02 PM, Boris Zbarsky wrote:
> > On 6/28/13 10:01 PM, Boris Zbarsky wrote:
> >> On 6/28/13 5:06 PM, Tab Atkins Jr. wrote:
> >>
> >>> getElementById("foo") is just querySelector("#foo")
> >>
> >> This is actually false. For example, getElementById("foo:bar") is
> >> just querySelector("#foo\\:bar"), which is ... nonobvious.
> >
> > And today someone asked me how to do the equivalent of
> > getElementById("\n") with querySelector. That one is even more
> > non-obvious.
>
> But it's already been suggested--by you--that we need a function to
> CSS-escape a string, which seems to solve the that problem trivially
> (for users).
Leaving aside the issue that "CSS-escape" is more than one operation
depending on what kind of token you're creating, I don't think it's
actually as trivial as you think.
document.getElementById(id)
...becomes:
document.querySelector('#' + escapeCSSIdent(id))
...which is a lot less pretty and understandable, especially when you
consider that many authors are actually coming from:
document.all[id]
...which is briefer than either, and still self-explanatory.
I feel this is a case where we're not putting authors first, but are
instead putting spec purity first.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Thu, Oct 10, 2013 at 9:22 AM, Boris Zbarsky wrote:
> On 10/10/13 10:15 AM, Glenn Maynard wrote:
>
>> When I'm doing this I just make sure that the strings don't need
>> escaping in the first place. Many of these look like they do that
>> (probably most "ID" cases are things like random numbers or
>> alphanumerics).
>>
>
> Let's take a look at Simon's examples from actual web pages:
>
> .querySelectorAll("#"+M+" "+m)
> .querySelectorAll('.'+classes[**i])
>
> If M is a random number, it needs escaping. Similar if classes[i] is a
> random number. In particular, ID and class selectors cannot start with a
> digit.
That's why I said "many". There are obviously several cases that do need
escaping.
> FWIW, I rarely use IDs at all: I use classes, even if there will
>> probably only be one of something.
>>
>
> Classes have the same syntax as IDs in CSS (both are identifiers), so it's
> the same issue.
>
My point was that I never use getElementById (and getElementsByClassName
returns an array, so it's wrong too).
--
Glenn Maynard
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 10/10/13 10:15 AM, Glenn Maynard wrote:
When I'm doing this I just make sure that the strings don't need
escaping in the first place. Many of these look like they do that
(probably most "ID" cases are things like random numbers or alphanumerics).
Let's take a look at Simon's examples from actual web pages:
.querySelectorAll("#"+M+" "+m)
.querySelectorAll('.'+classes[i])
If M is a random number, it needs escaping. Similar if classes[i] is a
random number. In particular, ID and class selectors cannot start with
a digit.
FWIW, I rarely use IDs at all: I use classes, even if there will
probably only be one of something.
Classes have the same syntax as IDs in CSS (both are identifiers), so
it's the same issue.
-Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Thu, Oct 10, 2013 at 6:06 AM, Simon Pieters wrote:
> $('li[id = ' + textId + ']', $slideshow3485780.context)
> $('[n_id='+allN_id+'] .notificationContainer a span')
> $('.recommend > .bd.b_con ul[city="'+city1+'"]')
>
> (The above is just a small subset of some interesting cases.)
>
> I didn't see a single case that actually used an escaping utility.
When I'm doing this I just make sure that the strings don't need escaping
in the first place. Many of these look like they do that (probably most
"ID" cases are things like random numbers or alphanumerics).
FWIW, I rarely use IDs at all: I use classes, even if there will probably
only be one of something. (Once templates enter the picture, IDs don't
make sense, so I generally just avoid them.)
On Thu, Oct 10, 2013 at 8:41 AM, Glenn Adams wrote:
> Given the existence of Window.escape(), i.e., the JS escape(string)
> function property of the Global object, I wonder if choosing a longer,
> different name would be better to avoid confusion.
>
I think the "CSS" scope makes it perfectly clear and unambiguous.
--
Glenn Maynard
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Thu, 10 Oct 2013 15:41:41 +0200, Glenn Adams wrote: I've added CSS.escape(foo). Given the existence of Window.escape(), i.e., the JS escape(string) function property of the Global object, I wonder if choosing a longer, different name would be better to avoid confusion. You'd actually write "CSS.escape", so that's basically the longer, different name. Is that sufficient? -- Simon Pieters Opera Software
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
bcc www-style, context http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0075.html On Thu, 10 Oct 2013 13:06:58 +0200, Simon Pieters wrote: So, in cluclusion, it appears that there is *some* demand for this. The common case is escaping as ident. An API to escape as ident could be used for escaping strings, too. In order to not make people think more than just remembering to escape at all, it might be a good idea to just have one API to serve both cases, e.g. CSS.escape(foo). I've added CSS.escape(foo). https://dvcs.w3.org/hg/csswg/rev/09466af95185 -- Simon Pieters Opera Software
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Thu, 10 Oct 2013 02:40:30 +0200, Glenn Maynard wrote:
On Wed, Oct 9, 2013 at 7:02 PM, Boris Zbarsky wrote:
On 6/28/13 10:01 PM, Boris Zbarsky wrote:
On 6/28/13 5:06 PM, Tab Atkins Jr. wrote:
getElementById("foo") is just querySelector("#foo")
This is actually false. For example, getElementById("foo:bar") is just
querySelector("#foo\\:bar"), which is ... nonobvious.
And today someone asked me how to do the equivalent of
getElementById("\n") with querySelector. That one is even more
non-obvious.
A newline isn't conforming in id="" in HTML, so it's not a case we need to
consider here.
But it's already been suggested--by you--that we need a function to
CSS-escape a string, which seems to solve the that problem trivially (for
users).
I often do things like saving an element's elem.dataset.someId, and then
finding the element again later by saying
container.querySelector('[data-some-id="' + saved_id + '"]'. (That lets
me
find the element later, even if it's been replaced by a new element,
which
doesn't work if I just save a reference.) That would help there, too,
since I wouldn't need to make sure that my IDs don't need to be escaped.
That wouldn't actually need CSS ident escaping, but CSS string escaping.
The former would *work*, though, I guess, but is technically overkill.
I grepped through webdevdata.org's 2013 june data set for querySelector
and querySelectorAll and $ to get an idea about what people are doing:
Maybe needs to escape as string:
.querySelectorAll("[id='"+n+"'] "+b)
.querySelectorAll('[id="'+f+'"]')
$("[href='#"+adid+"']")
$('#mainMenu > ul > li > ul > li > a[href="' + theMenu.split('?') ...
$("li.zone7-li[data-id='" + id + "']")
$('.flex-control-nav li#left div[id="'+slider.currentSlide+'"]')
Maybe needs to escape as ident:
.querySelectorAll('.' + className)
.querySelectorAll("#"+M+" "+m)
.querySelectorAll("."+e.faibl)
.querySelectorAll('.'+classes[i])
.querySelector('#bet_event' + eid)
.querySelector('#' + sections[sec].id + ' .d' +
new_datetime.getLSHFormatDate('%d_%m_%Y')
$('iframe#'+iframeId)
$('#'+id+' ul li .item-thumbnail')
$('#'+settings.containerHoverID, this)
$("#focos .losfocos"+foco)
$("#" + hide + "_header")
$('.'+x)
$("#beloFBShare"+id[1])
$("#"+b.source)
$("#"+b.target)
$("#JS_expr_num_nav_"+window._current_expr_num)
$('#'+divTarget)
$("#"+divNum)
$('#' + id + '_ed')
$('.topstory-nav a.'+itemNo)
$('div#'+teaser_id+' div.textholder')
$('li[id = ' + textId + ']', $slideshow3485780.context)
$('[n_id='+allN_id+'] .notificationContainer a span')
$('.recommend > .bd.b_con ul[city="'+city1+'"]')
(The above is just a small subset of some interesting cases.)
I didn't see a single case that actually used an escaping utility.
Searching for code that uses Mathias' cssesc gives only one file that uses
it in github:
https://github.com/getlantern/lantern-ui/blob/aa1a3f4307f093070baa2d7e405cdecaa055108c/app/js/vis.js
I did however find more instances (528) by searching for "escapeSelector":
https://github.com/search?l=javascript&q=escapeSelector&ref=searchresults&type=Code
So, in cluclusion, it appears that there is *some* demand for this. The
common case is escaping as ident. An API to escape as ident could be used
for escaping strings, too. In order to not make people think more than
just remembering to escape at all, it might be a good idea to just have
one API to serve both cases, e.g. CSS.escape(foo).
I don't think that adding an API to escape a CSS ident means that it's a
good idea to not have e.g. getElementById on DocumentFragment. Most people
don't escape their stuff, so only providing a selector API that requires
escaping seems like the net effect would be more buggy code.
--
Simon Pieters
Opera Software
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 10/9/13 8:40 PM, Glenn Maynard wrote: But it's already been suggested--by you--that we need a function to CSS-escape a string Sure. This was just an additional data point as to why: CSS escaping a newline is not very obvious. which seems to solve the that problem trivially (for users). The ones that know to use it, right. -Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
Eventually ES6 template strings [1] will make this awesome, as you'll do
querySelector(css`\n`)
or
querySelector(css`[data-some-id=${myId}]`)
or even
qs`[data-some-id=${myId}]`
But someone has to write these functions (css and/or qs) and there's no point
in creating standard versions until template strings are actually in browsers.
(Well, modulo transpilers.) In the meantime a CSS escaper function would be
great and could be used to much more easily prolyfill such template string
functions, or be useful independently. So, uh, +1 to that idea.
[1]: http://www.slideshare.net/domenicdenicola/es6-the-awesome-parts/23
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Wed, Oct 9, 2013 at 7:02 PM, Boris Zbarsky wrote:
> On 6/28/13 10:01 PM, Boris Zbarsky wrote:
>
>> On 6/28/13 5:06 PM, Tab Atkins Jr. wrote:
>>
>>> getElementById("foo") is just querySelector("#foo")
>>>
>>
>> This is actually false. For example, getElementById("foo:bar") is just
>> querySelector("#foo\\:bar"), which is ... nonobvious.
>>
>
> And today someone asked me how to do the equivalent of
> getElementById("\n") with querySelector. That one is even more non-obvious.
But it's already been suggested--by you--that we need a function to
CSS-escape a string, which seems to solve the that problem trivially (for
users).
I often do things like saving an element's elem.dataset.someId, and then
finding the element again later by saying
container.querySelector('[data-some-id="' + saved_id + '"]'. (That lets me
find the element later, even if it's been replaced by a new element, which
doesn't work if I just save a reference.) That would help there, too,
since I wouldn't need to make sure that my IDs don't need to be escaped.
--
Glenn Maynard
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 6/28/13 10:01 PM, Boris Zbarsky wrote:
On 6/28/13 5:06 PM, Tab Atkins Jr. wrote:
getElementById("foo") is just querySelector("#foo")
This is actually false. For example, getElementById("foo:bar") is just
querySelector("#foo\\:bar"), which is ... nonobvious.
And today someone asked me how to do the equivalent of
getElementById("\n") with querySelector. That one is even more non-obvious.
-Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Fri, 06 Sep 2013 13:20:01 +0100, Simon Pieters wrote:
Such a function already exists in the wild btw:
http://mothereff.in/css-escapes
So the use case is getting an element by id with an "untrusted" id as
input, in an element or document fragment as opposed to the document?
I wouldn't call it "untrusted". It's needed to correctly find arbitrary ID.
It's not too eccentric to have non-alphanumeric IDs. For example you need
to use `[]` in form element name to receive multiple values in PHP, and it
makes sense for form-generating libraries to use same name and ID.
I don't understand "deprecation" of getElementById().
querySelector('#'+CSS.escapeIdent(id)) is significantly worse: less
readable, slower (generates garbage strings) and error-prone (unescaped
incorrect use is much easier than the correct use).
It's like deprecating indexOf(), because properly-escaped regular
expressions can do the same.
getElementById() is a very well-known API. It's pretty convenient. It
cannot be removed from the platform, so every browser already has to
implement it and cost of exposing it on document fragments should be
minimal.
Maybe it's not "cool", but keeping it away from document fragments buys
nothing, and just makes the platform less consistent.
--
regards, Kornel
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Fri, 06 Sep 2013 16:42:47 +0200, Boris Zbarsky wrote: On 9/6/13 8:20 AM, Simon Pieters wrote: So the use case is getting an element by id with an "untrusted" id as input, in an element or document fragment as opposed to the document? Or getting elements by tag name in a document fragment, for that matter (though "weird" chars in tag names are harder to produce; largely limited to leading digits). Leading digits in tag names is not possible. Valid tag names in HTML/SVG/MathML all use non-weird chars. -- Simon Pieters Opera Software
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Fri, Sep 6, 2013 at 4:22 AM, Anne van Kesteren wrote: > On Fri, Sep 6, 2013 at 2:50 AM, Boris Zbarsky wrote: >> In that case I think we need to add a function to the platform that >> CSS-escapes a string. > > Maybe a thing for window.CSS? Simon? Yeah, exposing window.CSS.escapeIdent(DOMString) would make sense. As noted, this is useful for ids, for tag names, and maybe even things like attribute names and values. ~TJ
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 9/6/13 8:20 AM, Simon Pieters wrote: So the use case is getting an element by id with an "untrusted" id as input, in an element or document fragment as opposed to the document? Or getting elements by tag name in a document fragment, for that matter (though "weird" chars in tag names are harder to produce; largely limited to leading digits). -Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Fri, 06 Sep 2013 14:43:14 +0200, Scott González wrote: For jQuery, the answer tends to be "it doesn't matter." There are very few places where we treat in-document and out-of-document situations differently. OK. There's http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#dom-label-control but it only works when in a document. Maybe that should be changed, though. -- Simon Pieters Opera Software
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Fri, Jun 28, 2013 at 6:51 PM, Tab Atkins Jr. wrote: > On Fri, Jun 28, 2013 at 2:28 PM, Zirak A wrote: > > Besides my personal aversion towards selectors being in the DOM API, > there's > > also the simple fact that it makes sense for document fragments to have > these > > methods. > > That's far from obvious, given that I don't think it makes sense to > spread those obsolete methods around any further. They were already spread to ShadowRoot. Does anyone have a reference to that discussion that led to that decision? It seems like if they're being added to ShadowRoot, which inherits from DocumentFragment, we might as well just add them to DocumentFragment and be done with it. At least from a non-implementor's view that seems to make sense.
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Fri, Sep 6, 2013 at 8:40 AM, Simon Pieters wrote: > On Fri, 06 Sep 2013 14:21:24 +0200, Scott González < > scott.gonza...@gmail.com> wrote: > >> Yes. Take the example of finding the input associated with a label: >> >> foo >> >> >> If you have a reference to the label and you want to find the input, you >> need to escape the value of the for attribute before querying. >> > > In this example, are the elements in the document? For jQuery, the answer tends to be "it doesn't matter." There are very few places where we treat in-document and out-of-document situations differently.
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Fri, 06 Sep 2013 14:21:24 +0200, Scott González wrote: On Fri, Sep 6, 2013 at 8:20 AM, Simon Pieters wrote: So the use case is getting an element by id with an "untrusted" id as input, in an element or document fragment as opposed to the document? Yes. Take the example of finding the input associated with a label: foo If you have a reference to the label and you want to find the input, you need to escape the value of the for attribute before querying. In this example, are the elements in the document? -- Simon Pieters Opera Software
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Fri, Sep 6, 2013 at 8:20 AM, Simon Pieters wrote: > So the use case is getting an element by id with an "untrusted" id as > input, in an element or document fragment as opposed to the document? > Yes. Take the example of finding the input associated with a label: foo If you have a reference to the label and you want to find the input, you need to escape the value of the for attribute before querying.
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Fri, 06 Sep 2013 13:22:34 +0200, Anne van Kesteren wrote: On Fri, Sep 6, 2013 at 2:50 AM, Boris Zbarsky wrote: In that case I think we need to add a function to the platform that CSS-escapes a string. Maybe a thing for window.CSS? Simon? Such a function already exists in the wild btw: http://mothereff.in/css-escapes So the use case is getting an element by id with an "untrusted" id as input, in an element or document fragment as opposed to the document? -- Simon Pieters Opera Software
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Fri, Sep 6, 2013 at 2:50 AM, Boris Zbarsky wrote: > In that case I think we need to add a function to the platform that > CSS-escapes a string. Maybe a thing for window.CSS? Simon? Such a function already exists in the wild btw: http://mothereff.in/css-escapes -- http://annevankesteren.nl/
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 9/5/13 6:02 AM, Anne van Kesteren wrote:
Having said that, our current plan is to rely on the Selectors API (2)
In that case I think we need to add a function to the platform that
CSS-escapes a string. Because right now, writing
querySelector("#" + id)
is a total footgun unless you control the id. In particular, if you're
a library you're in trouble...
but the hope is that .querySelector("#test") will be fast
enough.
As I explained in the thread, they have quite different behavior:
getElementById takes the ID, but querySelector needs a CSS-escaped form
of the ID.
I'm happy to raise this point on www-dom if you want. Just let me know.
-Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Fri, Jun 28, 2013 at 9:19 PM, Zirak A wrote:
> Currently, a DocumentFragment only inherits from Node, and thus loses methods
> like getElementById. However, the Selector API
> (http://www.w3.org/TR/selectors-api/) defines querySelector and
> querySelectorAll on document fragments.
> My proposal is to add getElementById (which makes sense, as the document
> fragment is a root node), getElementsByTagName (and its namespace-sensitive
> version), getElementsByClassName and getElementsByName - in short, all of the
> general selection methods available on the Document.
Per http://dom.spec.whatwg.org/ this is the wrong forum for DOM.
Having said that, our current plan is to rely on the Selectors API (2)
and slowly move away from getElement* friends over time, as their
return values are less than optimal. getElementById is an exception to
this, but the hope is that .querySelector("#test") will be fast
enough. If it turns out to be a problem, we should re-evaluate at that
point. Concrete suggestions for new traversal APIs should be discussed
on www-...@w3.org or the DOM bug database until we decide the more
appropriate forum is here, it'd be unfair to the existing community
otherwise.
If you think I should reply to any of the remainder of this thread
please let me know, but I hope this general answer is sufficient.
--
http://annevankesteren.nl/
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Jul 28, 2013, at 4:24 PM, Jonas Sicking wrote: > On Sun, Jul 28, 2013 at 1:59 PM, Ojan Vafai wrote: >> >> I was just picturing lazy computing the list. You don't need to compute the >> list until you query the length or index into the NodeList, at which point, >> if it's a static NodeList, you compute the whole thing in one go. If all you >> ever do is grab the iterator, then no need to compute the list. So, the >> example you give above would not precompute. How common is it for an author to call querySelectorAll and then NOT iterate over it? If the author simply wanted the first element, then the author should be calling querySelector instead. >> Now that I put it in writing, the obvious problem with this is that it's a >> change in semantics. If you querySelectorAll and then modify the DOM before >> reading the length or an index, then you get a different list. :( > > It's not just a change in semantics, it's a change in behavior. To > keep the same behavior you would have to make the static NodeList > observe the DOM and precompute itself as soon as the DOM was modified. > > I.e. static NodeLists would incur the same performance problems that > Ryosuke expressed concern about that live NodeLists have. > > So yeah, I don't think it's an option. > > In general, I'm not a big fan of anything that adds capabilities to > "all NodeLists". This has been brought up in the past when people > suggested adding the ability to observe changes to "all NodeLists". > > It's not at all obvious to me that in *all* situations where we use > NodeLists that it is desired to be able to iterate the results lazily. > Requiring that might force implementations to spend a lot of time > implementing something that doesn't have use cases. > > We should think of NodeLists as simple Arrays. And it's clear that we > don't want to force any function that returns an Array to be able to > lazily compute that Array using an iterator. Keep in mind that the > laziness is observable, so it's not a valid implementation strategy to > only do the lazyness where there are clear performance benefits. Yeah. We could copy-on-write; i.e. do not allocate a node list as an array until DOM is about to be modified. But it's quite tricky to do this correctly. What are specific use cases under which statically allocating a node list is lower? - R. Niwa
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Sun, Jul 28, 2013 at 1:59 PM, Ojan Vafai wrote:
> On Sun, Jul 28, 2013 at 11:10 AM, Boris Zbarsky wrote:
>>
>> On 7/27/13 10:58 AM, Ojan Vafai wrote:
>>>
>>> var iterator = document.querySelectorAll('div').iterator(); <--- does
>>> some magic to not precompute the whole list
>>
>>
>> Well, so... not precompute but make it some sort of live, or not
>> precompute but represent a frozen set of nodes?
>>
>> What should happen with this situation:
>>
>> var list = document.querySelectorAll('div');
>> var iterator = list.iterator();
>>
>> Should the list of nodes be precomputed in this case?
>>
>> Basically, the magic sounds like it's ... very magical. Magical enough
>> that authors would have a tough time with this setup, even ignoring
>> implementation concerns.
>
>
> I was just picturing lazy computing the list. You don't need to compute the
> list until you query the length or index into the NodeList, at which point,
> if it's a static NodeList, you compute the whole thing in one go. If all you
> ever do is grab the iterator, then no need to compute the list. So, the
> example you give above would not precompute.
>
> Now that I put it in writing, the obvious problem with this is that it's a
> change in semantics. If you querySelectorAll and then modify the DOM before
> reading the length or an index, then you get a different list. :(
It's not just a change in semantics, it's a change in behavior. To
keep the same behavior you would have to make the static NodeList
observe the DOM and precompute itself as soon as the DOM was modified.
I.e. static NodeLists would incur the same performance problems that
Ryosuke expressed concern about that live NodeLists have.
So yeah, I don't think it's an option.
In general, I'm not a big fan of anything that adds capabilities to
"all NodeLists". This has been brought up in the past when people
suggested adding the ability to observe changes to "all NodeLists".
It's not at all obvious to me that in *all* situations where we use
NodeLists that it is desired to be able to iterate the results lazily.
Requiring that might force implementations to spend a lot of time
implementing something that doesn't have use cases.
We should think of NodeLists as simple Arrays. And it's clear that we
don't want to force any function that returns an Array to be able to
lazily compute that Array using an iterator. Keep in mind that the
laziness is observable, so it's not a valid implementation strategy to
only do the lazyness where there are clear performance benefits.
/ Jonas
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Sun, Jul 28, 2013 at 11:10 AM, Boris Zbarsky wrote:
> On 7/27/13 10:58 AM, Ojan Vafai wrote:
>
>> var iterator = document.querySelectorAll('**div').iterator(); <--- does
>> some magic to not precompute the whole list
>>
>
> Well, so... not precompute but make it some sort of live, or not
> precompute but represent a frozen set of nodes?
>
> What should happen with this situation:
>
> var list = document.querySelectorAll('**div');
> var iterator = list.iterator();
>
> Should the list of nodes be precomputed in this case?
>
> Basically, the magic sounds like it's ... very magical. Magical enough
> that authors would have a tough time with this setup, even ignoring
> implementation concerns.
I was just picturing lazy computing the list. You don't need to compute the
list until you query the length or index into the NodeList, at which point,
if it's a static NodeList, you compute the whole thing in one go. If all
you ever do is grab the iterator, then no need to compute the list. So, the
example you give above would not precompute.
Now that I put it in writing, the obvious problem with this is that it's a
change in semantics. If you querySelectorAll and then modify the DOM before
reading the length or an index, then you get a different list. :(
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 7/27/13 10:58 AM, Ojan Vafai wrote:
var iterator = document.querySelectorAll('div').iterator(); <--- does
some magic to not precompute the whole list
Well, so... not precompute but make it some sort of live, or not
precompute but represent a frozen set of nodes?
What should happen with this situation:
var list = document.querySelectorAll('div');
var iterator = list.iterator();
Should the list of nodes be precomputed in this case?
Basically, the magic sounds like it's ... very magical. Magical enough
that authors would have a tough time with this setup, even ignoring
implementation concerns.
-Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
Isn't that what the NodeIterator and TreeWalker DOM APIs were for?
Sincerely,
James Greene
On Jul 27, 2013 12:58 PM, "Ojan Vafai" wrote:
> On Thu, Jul 25, 2013 at 1:42 PM, Jonas Sicking wrote:
>
> > On Thu, Jul 25, 2013 at 9:05 AM, Boris Zbarsky wrote:
> > > On 7/24/13 10:42 PM, Jussi Kalliokoski wrote:
> > >>
> > >> Argh, I had forgotten about live NodeLists. OK, this is a reason that
> > >> resonates with me and justifies calling these methods obsolete. Too
> bad
> > >> these methods are so badly flawed
> > >
> > >
> > > Fwiw, I think the performance impact of live NodeLists is ... unclear.
> > Their
> > > existence does mean that you have to deal with DOM mutations changing
> the
> > > lists, but them being live also means you can make the list getters
> much
> > > faster in cases when the caller doesn't actually want the entire list.
> >
> > And, as importantly, it also means that for multiple consecutive calls
> > to get the list, say inside of a loop, can return the same result
> > object. I.e. you don't have to re-walk the DOM for every iteration
> > through the loop.
> >
>
> I think these are good points of what is lost by using static NodeLists. I
> still feel pretty strongly though that these benefits don't outweigh the
> costs. If we want to give people most of the benefits of live NodeLists
> without the costs we could expose an iterator API:
>
> var iterator = document.querySelectorAll('div').iterator(); <--- does some
> magic to not precompute the whole list
> while (let current = iterator.next()) { ... }
>
> And next always does the walk from the current node. So, if you add a div
> before the current node, this specific iterator won't hit it, but if you
> add a div after it would. I'm not sure what should happen though if you
> remove the node that's the current node. I think I'm OK with the iterator
> just returning null for the next() call in that case.
>
> This gets the performance benefits of live NodeLists, I think meets the
> main use-cases of not wanting to walk the whole DOM, but doesn't require
> the browser to do a lot of metadata tracking as you go.
>
> Ojan
>
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Thu, Jul 25, 2013 at 1:42 PM, Jonas Sicking wrote:
> On Thu, Jul 25, 2013 at 9:05 AM, Boris Zbarsky wrote:
> > On 7/24/13 10:42 PM, Jussi Kalliokoski wrote:
> >>
> >> Argh, I had forgotten about live NodeLists. OK, this is a reason that
> >> resonates with me and justifies calling these methods obsolete. Too bad
> >> these methods are so badly flawed
> >
> >
> > Fwiw, I think the performance impact of live NodeLists is ... unclear.
> Their
> > existence does mean that you have to deal with DOM mutations changing the
> > lists, but them being live also means you can make the list getters much
> > faster in cases when the caller doesn't actually want the entire list.
>
> And, as importantly, it also means that for multiple consecutive calls
> to get the list, say inside of a loop, can return the same result
> object. I.e. you don't have to re-walk the DOM for every iteration
> through the loop.
>
I think these are good points of what is lost by using static NodeLists. I
still feel pretty strongly though that these benefits don't outweigh the
costs. If we want to give people most of the benefits of live NodeLists
without the costs we could expose an iterator API:
var iterator = document.querySelectorAll('div').iterator(); <--- does some
magic to not precompute the whole list
while (let current = iterator.next()) { ... }
And next always does the walk from the current node. So, if you add a div
before the current node, this specific iterator won't hit it, but if you
add a div after it would. I'm not sure what should happen though if you
remove the node that's the current node. I think I'm OK with the iterator
just returning null for the next() call in that case.
This gets the performance benefits of live NodeLists, I think meets the
main use-cases of not wanting to walk the whole DOM, but doesn't require
the browser to do a lot of metadata tracking as you go.
Ojan
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Thu, Jul 25, 2013 at 9:05 AM, Boris Zbarsky wrote: > On 7/24/13 10:42 PM, Jussi Kalliokoski wrote: >> >> Argh, I had forgotten about live NodeLists. OK, this is a reason that >> resonates with me and justifies calling these methods obsolete. Too bad >> these methods are so badly flawed > > > Fwiw, I think the performance impact of live NodeLists is ... unclear. Their > existence does mean that you have to deal with DOM mutations changing the > lists, but them being live also means you can make the list getters much > faster in cases when the caller doesn't actually want the entire list. And, as importantly, it also means that for multiple consecutive calls to get the list, say inside of a loop, can return the same result object. I.e. you don't have to re-walk the DOM for every iteration through the loop. / Jonas
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 7/24/13 10:42 PM, Jussi Kalliokoski wrote: Argh, I had forgotten about live NodeLists. OK, this is a reason that resonates with me and justifies calling these methods obsolete. Too bad these methods are so badly flawed Fwiw, I think the performance impact of live NodeLists is ... unclear. Their existence does mean that you have to deal with DOM mutations changing the lists, but them being live also means you can make the list getters much faster in cases when the caller doesn't actually want the entire list. -Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 7/24/13 5:39 PM, Ryosuke Niwa wrote: 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... I have a hard time reconciling that claim with either code-inspection of WebKit code, general considerations of what it takes to implement these methods, or the numbers I see in Chrome on http://jsperf.com/queryselector-vs-dom Now I realize that for querySelectorAll vs getElementsByClassName that microbenchmark largely shows the "reuse same list vs have to create a new list" difference, but real-life code would show such a difference too, in many cases. -Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 7/24/13 5:51 PM, James Greene wrote: While I'm not familiar with the spec for DocumentFragments, I've always consider them to be more equivalent to a detached element node than a document node. Fwiw, Element has a getElementsByClassName and getElementsByTagName. And SVGElement has getElementById. -Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Thu, Jul 25, 2013 at 3:39 AM, Ryosuke Niwa wrote: > > 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. > Argh, I had forgotten about live NodeLists. OK, this is a reason that resonates with me and justifies calling these methods obsolete. Too bad these methods are so badly flawed and that it's not worth the cost to try to fix those methods to return something other than a live NodeList. As for getElementById(), I'm not sure how useful that is by itself. Cheers, Jussi > On Jun 29, 2013, at 3:47 PM, Glenn Maynard wrote: > > > On Sat, Jun 29, 2013 at 4:55 PM, Tim Streater > 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 > >
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
While I'm not familiar with the spec for DocumentFragments, I've always consider them to be more equivalent to a detached element node than a document node. Keeping that interpretation in mind, adding these methods wouldn't make sense to me personally. Unless my understanding is completely off-base and fragments *are* supposed to be most similar to document nodes, I'd agree with the earlier suggestion that those who want this functionality should just add it themselves via JS. Sincerely, James Greene On Wed, Jul 24, 2013 at 7:39 PM, Ryosuke Niwa wrote: > > On Jun 28, 2013, at 5:32 PM, Zirak A 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. > > No. > > > The point here is that document fragments are documents - so they should > have a consistent API. > > No. > > > 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 wrote: > > > On Sat, Jun 29, 2013 at 4:55 PM, Tim Streater > 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 > >
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Jun 28, 2013, at 5:32 PM, Zirak A 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. No. > The point here is that document fragments are documents - so they should have > a consistent API. No. > 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 wrote: > On Sat, Jun 29, 2013 at 4:55 PM, Tim Streater 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
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
Boris Zbarsky, 2013-07-03 17:50 (Europe/Helsinki): On 7/3/13 3:58 AM, Mikko Rantalainen wrote: Boris Zbarsky, 2013-06-29 05:02 (Europe/Helsinki): On 6/28/13 6:51 PM, Tab Atkins Jr. wrote: querySelector is simply a more powerful querying function than the old DOM methods, And somewhat slower as a result, note. I'd *guess* that that difference is meaningless compared to walking the element tree or even doing hash lookup for the id You'd guess wrong, and I've got profiles to prove it. ;) OK. I stand corrected. With the real world performance difference, I'd prefer that getElementsByTagName() and getElementById() were supported for fragments, too. Pros: - Better optimized performance - Making API more similar to Document Cons: - Two extra methods in the namespace (however, nobody sane will use neither of the old method names for anything else so this can be ignored) -- Mikko
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
> (I've used querySelector exclusively for quite some time, and I find > arguments that querySelector isn't readable or "the wrong tool" to simply > not hold up. I find it more readable, actually, since I don't have to > change interfaces depending on whether I'm searching for an ID or a class.) > I think you just described the anti-pattern of readable code: a function that does more than one thing. Wrong/right tool, depends on the use case. Often times a Swiss knife will do the job of simply driving a screw. However, a screwdriver will be more suitable for screwing a lot of screws, and moreover when you see a screwdriver you know what it's going to be used for as opposed to for a Swiss knife it's hard to tell. Then again, if you don't know what's going to be thrown at you and you need to pack lightly, nothing as handy as a Swiss knife. Cheers, Jussi > > -- > Glenn Maynard > >
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 7/3/13 3:58 AM, Mikko Rantalainen wrote:
Boris Zbarsky, 2013-06-29 05:02 (Europe/Helsinki):
On 6/28/13 6:51 PM, Tab Atkins Jr. wrote:
querySelector is simply a more powerful querying function than the old
DOM methods,
And somewhat slower as a result, note.
If that's true, I would consider that as a bug. It should be really
simple for an UA implementation to optimize as following
querySelector("#foo") -> getElementById("foo")
They're not equivalent in general; see my comments earlier in this
thread. You have to actually parse the argument to querySelector with
something like a selector parser to see whether you can make this
optimization. Note that UAs already do this at that point, but there is
still more work than getElementById.
querySelectorAll("foo") -> getElementsByTagName("foo")
Those are also not equivalent. Much more so than the other, to the
point where optimizing this sanely is much harder. The thing on the
right selects on the qualified name while the thing on the left selects
on the localName. And they return different kinds of objects, too. So
something like this:
getElementsByTagName("foo")[1]
can be way faster than querySelectorAll("foo")[1], because the latter
has to walk the entire DOM while the former only has to walk to the
second .
Or, were you really talking about the difference between having to scan
the string given as a parameter to see if it looked like "simple"
selector that matches the old DOM method implementation?
For the #foo case, this is exactly right.
I'd *guess* that that difference is meaningless compared to
walking the element tree or even doing hash lookup for the id
You'd guess wrong, and I've got profiles to prove it. ;)
-Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
Boris Zbarsky, 2013-06-29 05:02 (Europe/Helsinki):
On 6/28/13 6:51 PM, Tab Atkins Jr. wrote:
querySelector is simply a more powerful querying function than the old
DOM methods,
And somewhat slower as a result, note.
If that's true, I would consider that as a bug. It should be really
simple for an UA implementation to optimize as following
querySelector("#foo") -> getElementById("foo")
querySelectorAll("foo") -> getElementsByTagName("foo")
as long the latter (internal) implementations were available and had
better performance.
Or, were you really talking about the difference between having to scan
the string given as a parameter to see if it looked like "simple"
selector that matches the old DOM method implementation? I understand
that JS+JIT allows faster method dispatching with getElementById() than
with querySelector() plus checking the characters of the first
parameter. I'd *guess* that that difference is meaningless compared to
walking the element tree or even doing hash lookup for the id which is
required to implement even the old DOM methods.
--
Mikko
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Mon, Jul 1, 2013 at 1:20 AM, Alexandre Morgaut wrote: > 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/.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 Yup. We in mozilla tried to get it removed. But Ian wouldn't remove it until all other vendors comitted to removing it from their implementation. And other vendors didn't respond until we gave up due to too much page breakage. I would say mozilla is still ok with removing this support from non-quirks pages, if you can get enough other vendors to commit to doing it too. It's a battle we lost fighting it on our own. / Jonas
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Mon, Jul 1, 2013 at 1:56 AM, Octavian Damiean wrote: > I completely agree with Jussi here. It's also not really constructive to > argue whether querySelector is more powerful not, we're talking about > consistency. > It's a little inconsistent to agree with something other than consistency, then telling people not to argue about anything but consistency. :) "Consistency" isn't a magic word that justifies things by itself. When it comes to backwards-compatibility with obsolete APIs, consistency often just means bloat. (I've used querySelector exclusively for quite some time, and I find arguments that querySelector isn't readable or "the wrong tool" to simply not hold up. I find it more readable, actually, since I don't have to change interfaces depending on whether I'm searching for an ID or a class.) -- Glenn Maynard
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
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/.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 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.morg...@4d.com
Web : www.4D.com
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Sun, Jun 30, 2013 at 9:44 PM,
Jussi Kalliokoski wrote:
> On Sat, Jun 29, 2013 at 5:01 AM, Boris Zbarsky 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
>
I completely agree with Jussi here. It's also not really constructive to
argue whether querySelector is more powerful not, we're talking about
consistency.
Cheers,
--
Octavian Damiean
GitHub: https://github.com/mainerror
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Sat, Jun 29, 2013 at 5:01 AM, Boris Zbarsky 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
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Sat, Jun 29, 2013 at 4:55 PM, Tim Streater 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. -- Glenn Maynard
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 29 Jun 2013 at 01:37, Tab Atkins Jr. wrote: > On Fri, Jun 28, 2013 at 5:32 PM, Zirak A 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). > > No, they're not. You're rewriting history. Selectors were never > meant as a layer over those methods; they were a completely separate > and independently-invented way to target elements for CSS's purposes. 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. -- Cheers -- Tim
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 6/28/13 8:32 PM, Zirak A wrote: The point here is that document fragments are documents Actually, no. They are not. getElementById on a document fragment, for example, would almost certainly be slower than on a document (which typically has a hashtable mapping ids to lists of elements). -Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 6/28/13 6:51 PM, Tab Atkins Jr. wrote: querySelector is simply a more powerful querying function than the old DOM methods, And somewhat slower as a result, note. -Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 6/28/13 5:06 PM, Tab Atkins Jr. wrote:
getElementById("foo") is just querySelector("#foo")
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.
-Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Fri, Jun 28, 2013 at 5:32 PM, Zirak A 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).
No, they're not. You're rewriting history. Selectors were never
meant as a layer over those methods; they were a completely separate
and independently-invented way to target elements for CSS's purposes.
I'm not sure of the precise dates, but I know that Selectors precede
at least some of those properties, maybe all.
Selectors are a better way to query documents, and they're extremely
well-known. All of the old DOM query methods translate directly into
simple selectors - qS("#foo"), qSA(".foo"), qSA("foo"), or
qSA("[name=foo]").
~TJ
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
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). - Original Message - From: Tab Atkins Jr. Sent: 06/28/13 11:52 PM To: Zirak A Subject: Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments On Fri, Jun 28, 2013 at 4:45 PM, Zirak A wrote: > My intention wasn't for this to be an argument whether the selectors API make > anything before them obsolete. The intention was to make the API more > consistent - if documents have a getElementById method, so should document > fragments. > I acknowledge that selectors let you write more complex queries, and that some > developers prefer them. However, others (like me) prefer using the "older" > methods like getElementById. As said, this is an attempt to make the API more > consistent, given that we already have methods like getElementById. While consistency with the past is good, it shouldn't be fetishized. Adding methods means more code in the browsers, which is a non-zero cost. When the requested feature is literally 100% obsoleted by another feature that already exists, there's really no reason to add the requested feature. Note that you can add these yourself, if desired, by adding methods to the DocumentFragment prototype that are defined in terms of querySelector. ~TJ
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Fri, Jun 28, 2013 at 4:45 PM, Zirak A wrote: > My intention wasn't for this to be an argument whether the selectors API make > anything before them obsolete. The intention was to make the API more > consistent - if documents have a getElementById method, so should document > fragments. > I acknowledge that selectors let you write more complex queries, and that some > developers prefer them. However, others (like me) prefer using the "older" > methods like getElementById. As said, this is an attempt to make the API more > consistent, given that we already have methods like getElementById. While consistency with the past is good, it shouldn't be fetishized. Adding methods means more code in the browsers, which is a non-zero cost. When the requested feature is literally 100% obsoleted by another feature that already exists, there's really no reason to add the requested feature. Note that you can add these yourself, if desired, by adding methods to the DocumentFragment prototype that are defined in terms of querySelector. ~TJ
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
My intention wasn't for this to be an argument whether the selectors API make anything before them obsolete. The intention was to make the API more consistent - if documents have a getElementById method, so should document fragments. I acknowledge that selectors let you write more complex queries, and that some developers prefer them. However, others (like me) prefer using the "older" methods like getElementById. As said, this is an attempt to make the API more consistent, given that we already have methods like getElementById. - Original Message - From: Tab Atkins Jr. Sent: 06/28/13 10:51 PM To: Zirak A Subject: Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments On Fri, Jun 28, 2013 at 2:28 PM, Zirak A wrote: > Because they may result in the same thing, but they have different semantic > meanings. I want to get an element by its id, not run a CSS selector. I want > to get elements by their tag names, not run a CSS selector. There's no semantic difference between the methods. querySelector is simply a more powerful querying function than the old DOM methods, capable of doing everything the old methods did and much more. > Besides my personal aversion towards selectors being in the DOM API, there's > also the simple fact that it makes sense for document fragments to have these > methods. That's far from obvious, given that I don't think it makes sense to spread those obsolete methods around any further. ~TJ
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Fri, Jun 28, 2013 at 3:20 PM, Tim Streater wrote:
>> From: Tab Atkins Jr.
>> Given that you have querySelector, why would you want the other
>> functions? getElementById("foo") is just querySelector("#foo"),
>> getElementsByTagName("foo") is just querySelectorAll("foo"), etc.
>
> In addition it's hardly obvious that this is what you do.
Assuming you know literally anything about CSS, yes, it is quite
obvious that that's what you do. "#foo" is an id selector.
If you don't know anything about CSS, I suggest learning at least the
basics. Attempting to do JS work without knowledge of CSS's abilities
will lead you to duplicate, badly, functionality already built into
CSS.
~TJ
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Fri, Jun 28, 2013 at 2:28 PM, Zirak A wrote: > Because they may result in the same thing, but they have different semantic > meanings. I want to get an element by its id, not run a CSS selector. I want > to get elements by their tag names, not run a CSS selector. There's no semantic difference between the methods. querySelector is simply a more powerful querying function than the old DOM methods, capable of doing everything the old methods did and much more. > Besides my personal aversion towards selectors being in the DOM API, there's > also the simple fact that it makes sense for document fragments to have these > methods. That's far from obvious, given that I don't think it makes sense to spread those obsolete methods around any further. ~TJ
