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
On Sat, Nov 2, 2013 at 1:59 AM, Boris Zbarsky bzbar...@mit.edu 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
(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
On 10/31/13 7:42 AM, Anne van Kesteren wrote:
On Wed, Oct 23, 2013 at 4:47 AM, Boris Zbarsky bzbar...@mit.edu 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
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
On Thu, 31 Oct 2013 06:48:00 +0100, Boris Zbarsky bzbar...@mit.edu 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
On Wed, Oct 23, 2013 at 4:47 AM, Boris Zbarsky bzbar...@mit.edu 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
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
* 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
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
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
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
* 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
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
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
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,script
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
On Wed, 23 Oct 2013 05:45:12 +0200, Boris Zbarsky bzbar...@mit.edu 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
On Fri, Oct 18, 2013 at 10:56 PM, Boris Zbarsky bzbar...@mit.edu 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
On Oct 22, 2013, at 4:00 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Oct 18, 2013 at 10:56 PM, Boris Zbarsky bzbar...@mit.edu 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
On Tue, Oct 22, 2013 at 7:42 PM, Ryosuke Niwa rn...@apple.com wrote:
On Oct 22, 2013, at 4:00 AM, Anne van Kesteren ann...@annevk.nl wrote:
So do you think we should add getElementById() to ParentNode in DOM?
Why not to Element?
ParentNode encompasses Document, DocumentFragment, and Element.
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
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
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
On 18 Oct 2013 at 22:56, Boris Zbarsky bzbar...@mit.edu posted, inter alia,
this code:
[1] The testcase:
!DOCTYPE html
script
document.write(svg id='root' width='0' height='0');
for (var i = 0; i 100; ++i) {
document.write(rect/);
}
document.write(rect id='test'/);
Hi Tim,
On 10/19/2013 07:03 PM, Tim Streater wrote:
On 18 Oct 2013 at 22:56, Boris Zbarsky bzbar...@mit.edu posted, inter alia,
this code:
[1] The testcase:
!DOCTYPE html
script
document.write(svg id='root' width='0' height='0');
for (var i = 0; i 100; ++i) {
On 19 Oct 2013 at 18:27, Ms2ger ms2...@gmail.com 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
On 15 Oct 2013 at 01:18, Glenn Maynard gl...@zewt.org wrote:
On Thu, Oct 10, 2013 at 1:41 PM, Ian Hickson i...@hixie.ch wrote:
[snip]
document.getElementById(id)
...becomes:
document.querySelector('#' + escapeCSSIdent(id))
...which is a lot less pretty and understandable,
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
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
On Fri, 18 Oct 2013, Tab Atkins Jr. wrote:
On Fri, Oct 18, 2013 at 11:09 AM, James Greene james.m.gre...@gmail.com
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.
On Oct 18, 2013, at 1:50 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 18 Oct 2013, Tab Atkins Jr. wrote:
On Fri, Oct 18, 2013 at 11:09 AM, James Greene james.m.gre...@gmail.com
wrote:
I would also love to see `getElementById` added to the
HTMLElement/Element interface. It would be nice to
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.
On 10 Oct 2013, at 15:05, Simon Pieters sim...@opera.com 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:
On Thu, 10 Oct 2013 17:52:49 +0200, Glenn Adams gl...@skynav.com 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
On Thu, Oct 10, 2013 at 1:41 PM, Ian Hickson i...@hixie.ch 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
On Thu, Oct 10, 2013 at 10:26 PM, Scott González
scott.gonza...@gmail.com 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
On Thu, 10 Oct 2013 02:40:30 +0200, Glenn Maynard gl...@zewt.org wrote:
On Wed, Oct 9, 2013 at 7:02 PM, Boris Zbarsky bzbar...@mit.edu 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
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 sim...@opera.com wrote:
So, in cluclusion, it appears that there is *some* demand for this. The
common case is escaping as ident. An API to
On Thu, 10 Oct 2013 15:41:41 +0200, Glenn Adams gl...@skynav.com 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.
On Thu, Oct 10, 2013 at 6:06 AM, Simon Pieters sim...@opera.com 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
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
On Thu, Oct 10, 2013 at 9:22 AM, Boris Zbarsky bzbar...@mit.edu 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
On Wed, 9 Oct 2013, Glenn Maynard wrote:
On Wed, Oct 9, 2013 at 7:02 PM, Boris Zbarsky bzbar...@mit.edu 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,
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
On Thu, Oct 10, 2013 at 8:51 PM, Boris Zbarsky bzbar...@mit.edu 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. ;)
On Fri, Sep 6, 2013 at 8:47 AM, Scott González scott.gonza...@gmail.comwrote:
On Fri, Jun 28, 2013 at 6:51 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Fri, Jun 28, 2013 at 2:28 PM, Zirak A zi...@mail.com wrote:
Besides my personal aversion towards selectors being in the DOM API,
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
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
On Wed, Oct 9, 2013 at 7:02 PM, Boris Zbarsky bzbar...@mit.edu 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
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
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).
On Fri, 06 Sep 2013 16:42:47 +0200, Boris Zbarsky bzbar...@mit.edu 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
On Fri, Sep 6, 2013 at 2:50 AM, Boris Zbarsky bzbar...@mit.edu 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
--
On Fri, 06 Sep 2013 13:22:34 +0200, Anne van Kesteren ann...@annevk.nl
wrote:
On Fri, Sep 6, 2013 at 2:50 AM, Boris Zbarsky bzbar...@mit.edu 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
On Fri, Sep 6, 2013 at 8:20 AM, Simon Pieters sim...@opera.com 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:
label
On Fri, 06 Sep 2013 14:21:24 +0200, Scott González
scott.gonza...@gmail.com wrote:
On Fri, Sep 6, 2013 at 8:20 AM, Simon Pieters sim...@opera.com 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?
On Fri, Sep 6, 2013 at 8:40 AM, Simon Pieters sim...@opera.com 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:
label for=foofoo/label
input id=foo
If you have a reference to the
On Fri, Jun 28, 2013 at 6:51 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Fri, Jun 28, 2013 at 2:28 PM, Zirak A zi...@mail.com 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
On Fri, 06 Sep 2013 14:43:14 +0200, Scott González
scott.gonza...@gmail.com 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
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
On Fri, Sep 6, 2013 at 4:22 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Sep 6, 2013 at 2:50 AM, Boris Zbarsky bzbar...@mit.edu 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
On Fri, Jun 28, 2013 at 9:19 PM, Zirak A zi...@mail.com 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.
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
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
On Sun, Jul 28, 2013 at 11:10 AM, Boris Zbarsky bzbar...@mit.edu 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
On Sun, Jul 28, 2013 at 1:59 PM, Ojan Vafai o...@chromium.org wrote:
On Sun, Jul 28, 2013 at 11:10 AM, Boris Zbarsky bzbar...@mit.edu 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
On Thu, Jul 25, 2013 at 1:42 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jul 25, 2013 at 9:05 AM, Boris Zbarsky bzbar...@mit.edu 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
Isn't that what the NodeIterator and TreeWalker DOM APIs were for?
Sincerely,
James Greene
On Jul 27, 2013 12:58 PM, Ojan Vafai o...@chromium.org wrote:
On Thu, Jul 25, 2013 at 1:42 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jul 25, 2013 at 9:05 AM, Boris Zbarsky bzbar...@mit.edu
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
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
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.
On Thu, Jul 25, 2013 at 9:05 AM, Boris Zbarsky bzbar...@mit.edu 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
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
On Thu, Jul 25, 2013 at 3:39 AM, Ryosuke Niwa rn...@apple.com 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
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
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
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
(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
On Sun, Jun 30, 2013 at 9:44 PM,
Jussi Kalliokoski jussi.kallioko...@gmail.com wrote:
On Sat, Jun 29, 2013 at 5:01 AM, Boris Zbarsky bzbar...@mit.edu wrote:
This is actually false. For example, getElementById(foo:bar) is just
querySelector(#foo\\:bar), which is ... nonobvious.
It
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
On Mon, Jul 1, 2013 at 1:56 AM, Octavian Damiean odami...@linux.comwrote:
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
On Mon, Jul 1, 2013 at 1:20 AM, Alexandre Morgaut
alexandre.morg...@4d.com 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 /
On Sat, Jun 29, 2013 at 5:01 AM, Boris Zbarsky bzbar...@mit.edu wrote:
This is actually false. For example, getElementById(foo:bar) is just
querySelector(#foo\\:bar), which is ... nonobvious.
It gets worse if you don't control the id that's passed in, because
getElementById(arg) becomes
On Sat, Jun 29, 2013 at 4:55 PM, Tim Streater t...@clothears.org.uk wrote:
But what I'm doing, I'm not doing for CSS purposes. I'm trying to find a
particular row, by id, in order to modify the contents of cells in that
row. I find it perverse to be using a style-related API call to do that.
On Fri, Jun 28, 2013 at 1:19 PM, Zirak A zi...@mail.com 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.
On 28 Jun 2013 at 21:19, Zirak A zi...@mail.com 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
the simple fact that it makes sense for document fragments to have these
methods.
- Original Message -
From: Tab Atkins Jr.
Sent: 06/28/13 09:06 PM
To: Zirak A
Subject: Re: [whatwg] Proposal: Adding methods like getElementById and
getElementsByTagName to DocumentFragments
On Fri, Jun 28
On 28 Jun 2013 at 22:28, Zirak A zi...@mail.com 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.
Quite so.
From: Tab
On Fri, Jun 28, 2013 at 2:28 PM, Zirak A zi...@mail.com 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
On Fri, Jun 28, 2013 at 3:20 PM, Tim Streater t...@clothears.org.uk 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
/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 zi...@mail.com wrote:
Because they may result in the same thing, but they have different semantic
meanings. I want
On Fri, Jun 28, 2013 at 4:45 PM, Zirak A zi...@mail.com 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
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
On Fri, Jun 28, 2013 at 5:32 PM, Zirak A zi...@mail.com wrote:
But that's a bit looking at it backwards. Selectors are supposed to be an
abstraction over these methods, not the other way around. The point here is
that
document fragments are documents - so they should have a consistent API.
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
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
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).
98 matches
Mail list logo
