On 2011-10-20 10:14, Sean Hogan wrote:
The primary use-case for matchesSelector() has been event-delegation,
and this is the same for matches(). More specifically, consider the
following scenario:
jQuery adds a new event registration method that uses event delegation
to mimic the behavior of:
Right now, the spec does however handle that use case by doing this:
document.querySelectorAll(:scope .foo, x);
Where x is either an individual element, or an Array, NodeList or
numerically indexed object containing 0 or more Elements.
(It does however limit the result only to elements
On 2011-11-15 15:13, Brian Kardell wrote:
Right now, the spec does however handle that use case by doing this:
document.querySelectorAll(:scope .foo, x);
Where x is either an individual element, or an Array, NodeList or
numerically indexed object containing 0 or more Elements.
(It does
This has been an interesting debate, but I'm still a little confused with the
outcome (if any).
Will someone summarize the current position on these issues:
1. Should find() and findAll() follow style scoped rules or not and how?
2. How does the presence of :scope affect find() and findAll()
3.
On Thu, Nov 10, 2011 at 2:57 PM, Travis Leithead
travis.leith...@microsoft.com wrote:
This has been an interesting debate, but I'm still a little confused with the
outcome (if any).
Will someone summarize the current position on these issues:
1. Should find() and findAll() follow style
On Thu, Nov 10, 2011 at 2:57 PM, Travis Leithead
travis.leith...@microsoft.com wrote:
This has been an interesting debate, but I'm still a little confused with the
outcome (if any).
Will someone summarize the current position on these issues:
1. Should find() and findAll() follow style
On Thu, Nov 10, 2011 at 11:33 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Nov 10, 2011 at 2:57 PM, Travis Leithead
travis.leith...@microsoft.com wrote:
This has been an interesting debate, but I'm still a little confused with
the outcome (if any).
Will someone summarize the current
On Fri, Oct 21, 2011 at 12:41 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Oct 20, 2011 at 2:33 PM, Lachlan Hunt lachlan.h...@lachy.id.au
wrote:
Not necessarily. It depends what exactly it means for a selector to
contain
:scope for determining whether or not to enable the implied :scope
What Tab said = )
On Sun, Oct 30, 2011 at 9:23 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Sat, Oct 29, 2011 at 8:28 PM, Cameron McCormack c...@mcc.id.au wrote:
On 20/10/11 3:50 AM, Alex Russell wrote:
I strongly agree that it should be an Array *type*, but I think just
returning a
On Sun, Oct 30, 2011 at 1:23 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Sat, Oct 29, 2011 at 11:28 PM, Cameron McCormack c...@mcc.id.au wrote:
On 20/10/11 3:50 AM, Alex Russell wrote:
I strongly agree that it should be an Array *type*, but I think just
returning a plain Array is the
On 31/10/11 1:56 PM, Alex Russell wrote:
Live NodeList instances don't need to be considered here. They're the
result of an API which generates them, and that API can be described
in terms of Proxies. No need to complicate NodeList or imply that we
need a different type.
Making NodeList
On 10/31/11 2:03 PM, Cameron McCormack wrote:
On 31/10/11 1:56 PM, Alex Russell wrote:
Live NodeList instances don't need to be considered here. They're the
result of an API which generates them, and that API can be described
in terms of Proxies. No need to complicate NodeList or imply that we
Ok, so we're down to not having full agreement on the following selectors:
On Mon, Oct 31, 2011 at 1:55 PM, Alex Russell slightly...@google.com wrote:
On Fri, Oct 21, 2011 at 12:41 AM, Jonas Sicking jo...@sicking.cc wrote:
e.findAll(body :scope div)
1, 2, 3, 4
e.findAll(body :scope div,
On 31/10/11 2:18 PM, Charles Pritchard wrote:
I don't understand what real array means, other than the prototype
equivalence.
There's also the [[DefineOwnProperty]] behaviour which is different from
normal objects. That kind of behaviour doesn't *need* to be handled by
making NodeLists real
On Mon, Oct 31, 2011 at 2:03 PM, Cameron McCormack c...@mcc.id.au wrote:
On 31/10/11 1:56 PM, Alex Russell wrote:
Live NodeList instances don't need to be considered here. They're the
result of an API which generates them, and that API can be described
in terms of Proxies. No need to
On Mon, Oct 31, 2011 at 2:18 PM, Charles Pritchard ch...@jumis.com wrote:
On 10/31/11 2:03 PM, Cameron McCormack wrote:
On 31/10/11 1:56 PM, Alex Russell wrote:
Live NodeList instances don't need to be considered here. They're the
result of an API which generates them, and that API can be
On 10/31/11 7:25 PM, Alex Russell wrote:
For JS, it just means having a working .length property (in all the
ways that Arrays allow it to be used). Arrays are identical to other
objects in all other respects.
No, they're not. For example, off the top of my head, they get
serialized
On 10/31/11 7:25 PM, Alex Russell wrote:
For JS, it just means having a working .length property (in all the
ways that Arrays allow it to be used). Arrays are identical to other
objects in all other respects.
No, they're not. For example, off the top of my head, they get
serialized
On 10/31/11 9:32 PM, Charles Pritchard wrote:
Structured cloning fails for NodeList, same as postMessage, because of
circular structure.
What circular structure? Structured clone can handle that.
It fails because it's a host object (based on its [[Class]]) that's not
whitelisted in the
On Sat, Oct 29, 2011 at 8:28 PM, Cameron McCormack c...@mcc.id.au wrote:
On 20/10/11 3:50 AM, Alex Russell wrote:
I strongly agree that it should be an Array *type*, but I think just
returning a plain Array is the wrong resolution to our NodeList
problem. WebIDL should specify that DOM List
On 30/10/11 2:28 PM, Cameron McCormack wrote:
On 20/10/11 3:50 AM, Alex Russell wrote:
I strongly agree that it should be an Array *type*, but I think just
returning a plain Array is the wrong resolution to our NodeList
problem. WebIDL should specify that DOM List types *are* Array types.
It's
On Sat, Oct 29, 2011 at 11:28 PM, Cameron McCormack c...@mcc.id.au wrote:
On 20/10/11 3:50 AM, Alex Russell wrote:
I strongly agree that it should be an Array *type*, but I think just
returning a plain Array is the wrong resolution to our NodeList
problem. WebIDL should specify that DOM List
On 20/10/11 3:50 AM, Alex Russell wrote:
I strongly agree that it should be an Array *type*, but I think just
returning a plain Array is the wrong resolution to our NodeList
problem. WebIDL should specify that DOM List types *are* Array types.
It's insane that we even have a NodeList type which
Yeah, I have to agree with the list here. If you allow one its unintuitive
to not allow it the same way in a group. The more exceptions and complexity
you add, the harder it is for someone to learn.
On Oct 25, 2011 10:16 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* Tab Atkins Jr. wrote:
On Wed, Oct 26, 2011 at 1:47 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Oct 25, 2011 at 10:43 AM, Yehuda Katz wyc...@gmail.com wrote:
e.findAll(div, :scope) // 0,context,1,2,3,4,5,6
Huh, why 0 and 6? What's the logic there? I would have expected it to
be a sorted union of the results
Your guesses are all right in terms of existing jQuery but one:
'div': [1, 2, 3, 4]
'': []
'#3': [3]
' div': [1, 2, 3]
'[foo=bar]': []
'[id=1]': [1]
':first-child': [1, 4]
'+ div': [5]
'~ div': [5, 6]
You can see the results live at http://jsfiddle.net/Dj3Ab/.
The basic rule is that if there is
On Tue, Oct 25, 2011 at 10:43 AM, Yehuda Katz wyc...@gmail.com wrote:
Your guesses are all right in terms of existing jQuery but one:
'div': [1, 2, 3, 4]
'': []
'#3': [3]
' div': [1, 2, 3]
'[foo=bar]': []
'[id=1]': [1]
':first-child': [1, 4]
'+ div': [5]
'~ div': [5, 6]
You can see the
On 26/10/11 4:43 AM, Yehuda Katz wrote:
Your guesses are all right in terms of existing jQuery but one:
'div': [1, 2, 3, 4]
'': []
'#3': [3]
' div': [1, 2, 3]
'[foo=bar]': []
'[id=1]': [1]
':first-child': [1, 4]
'+ div': [5]
'~ div': [5, 6]
You can see the results live at
On Tue, Oct 25, 2011 at 1:47 PM, Sean Hogan shogu...@westnet.com.au wrote:
I think allowing explicit :scope in findAll() will be perpetually confusing.
I can imagine someone looking at old code like:
e.findAll(div.foo span, div.bar :scope span)
and asking themselves what's the rule
On 26/10/11 7:51 AM, Tab Atkins Jr. wrote:
On Tue, Oct 25, 2011 at 1:47 PM, Sean Hoganshogu...@westnet.com.au wrote:
I think allowing explicit :scope in findAll() will be perpetually confusing.
I can imagine someone looking at old code like:
e.findAll(div.foo span, div.bar :scope span)
The only case I can think of where explicit scope might be useful would be
to filter out certain cases entirely:
elem.findAll(:scope:visible div);
elem.findAll(#contents :scope [data-foo])
It's probably fine to just say that you should do a match first in that
case, given the additional
On Tue, Oct 25, 2011 at 2:33 PM, Sean Hogan shogu...@westnet.com.au wrote:
On 26/10/11 7:51 AM, Tab Atkins Jr. wrote:
On Tue, Oct 25, 2011 at 1:47 PM, Sean Hoganshogu...@westnet.com.au
wrote:
I think allowing explicit :scope in findAll() will be perpetually
confusing.
I can imagine someone
On 26/10/11 9:28 AM, Tab Atkins Jr. wrote:
On Tue, Oct 25, 2011 at 2:33 PM, Sean Hoganshogu...@westnet.com.au wrote:
On 26/10/11 7:51 AM, Tab Atkins Jr. wrote:
On Tue, Oct 25, 2011 at 1:47 PM, Sean Hoganshogu...@westnet.com.au
wrote:
I think allowing explicit :scope in findAll() will be
The CSS grammar (http://www.w3.org/TR/selectors/#w3cselgrammar) has a
production for selector_group and selector. I would think that :scope would
be prepended to each selector, not the entire selector group.
-- Yehuda Katz
On Tuesday, October 25, 2011, Tab Atkins Jr. wrote:
On Tue, Oct 25,
* Tab Atkins Jr. wrote:
Did you not understand my example? el.find(+ foo, + bar) feels
really weird and I don't like it. I'm okay with a single selector
starting with a combinator, like el.find(+ foo), but not a selector
list.
Allowing + foo but not + foo, + bar would be really weird.
--
Björn
On Tue, Oct 25, 2011 at 4:56 PM, Ojan Vafai o...@chromium.org wrote:
On Tue, Oct 25, 2011 at 4:44 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* Tab Atkins Jr. wrote:
Did you not understand my example? el.find(+ foo, + bar) feels
really weird and I don't like it. I'm okay with a single
fwiw, jQuery doesn't properly handle the comma-separated case, but this is
most definitely a bug, caused by the naïve implementation that Alex showed
early on in this thread.
-- Yehuda
On Tuesday, October 25, 2011, Tab Atkins Jr. wrote:
On Tue, Oct 25, 2011 at 4:56 PM, Ojan Vafai
On 26/10/11 11:03 AM, Yehuda Katz wrote:
fwiw, jQuery doesn't properly handle the comma-separated case, but
this is most definitely a bug, caused by the naïve implementation that
Alex showed early on in this thread.
So no-one is actually using +foo, +bar? How common is +foo usage?
Sean
On Tue, Oct 25, 2011 at 4:58 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Tue, Oct 25, 2011 at 4:56 PM, Ojan Vafai o...@chromium.org wrote:
On Tue, Oct 25, 2011 at 4:44 PM, Bjoern Hoehrmann derhoe...@gmx.net
wrote:
* Tab Atkins Jr. wrote:
Did you not understand my example?
* Tab Atkins Jr. wrote:
On Tue, Oct 25, 2011 at 4:56 PM, Ojan Vafai o...@chromium.org wrote:
On Tue, Oct 25, 2011 at 4:44 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* Tab Atkins Jr. wrote:
Did you not understand my example? el.find(+ foo, + bar) feels
really weird and I don't like it. I'm
On 23/10/11 5:44 AM, Timmy wrote:
On Oct 21, 2011, at 7:57 PM, Sean Hogan wrote:
It was definitely not a design flaw in QSA. As Alex's sample code shows it is
possible to get findAll() behavior using QSA.
I think that further supports my argument. JS libraries have commonly
considered this
On Oct 21, 2011, at 7:57 PM, Sean Hogan wrote:
It was definitely not a design flaw in QSA. As Alex's sample code shows it is
possible to get findAll() behavior using QSA.
I think that further supports my argument. JS libraries have commonly
considered this to be an oversight in the design of
On Thu, Oct 20, 2011 at 2:33 PM, Lachlan Hunt lachlan.h...@lachy.id.au
wrote:
Not necessarily. It depends what exactly it means for a selector to
contain
:scope for determining whether or not to enable the implied :scope
behaviour. Consider:
foo.find(:not(:scope));
Ooh, this is an
On Oct 20, 2011, at 4:34 PM, Tab Atkins Jr. wrote:
On Thu, Oct 20, 2011 at 12:09 PM, Jonas Sicking jo...@sicking.cc wrote:
Let's do the general discussion about how live and non-live NodeLists
should behave in a separate thread.
Yes, let's. ^_^
The immediate question here is how
On 20/10/11 12:39 AM, Timmy Willison wrote:
From the perspective of building a selector engine, I think all
selector engines need something like .findAll, and not something like
:scope.
On Tue, Oct 18, 2011 at 8:00 PM, Alex Russell slightly...@google.com
mailto:slightly...@google.com wrote:
On 20/10/11 1:07 PM, Jonas Sicking wrote:
On Tue, Oct 18, 2011 at 9:42 AM, Alex Russellslightly...@google.com wrote:
Lachlan and I have been having an...um...*spirited* twitter discussion
regarding querySelectorAll, the (deceased?) queryScopedSelectorAll,
and :scope. He asked me to continue
On Wed, Oct 19, 2011 at 11:14 PM, Sean Hogan shogu...@westnet.com.au wrote:
I do however like the idea that if :scope appears in the selector,
then this removes the prepending of :scope to that selector group.
Is there a reason not to do that?
1. Already supported (in the draft spec) by
On 20/10/11 5:41 PM, Jonas Sicking wrote:
On Wed, Oct 19, 2011 at 11:14 PM, Sean Hoganshogu...@westnet.com.au wrote:
I do however like the idea that if :scope appears in the selector,
then this removes the prepending of :scope to that selector group.
Is there a reason not to do that?
1.
On Thu, Oct 20, 2011 at 14:08, Tab Atkins Jr. jackalm...@gmail.com wrote:
style scoped should (I think) have three cases:
1. Selector without :scope - same as .find
2. Selector with :scope - Same as #1, but also including the context node.
3. Selector in @global - run the selector across the
On Thu, Oct 20, 2011 at 14:52, Jonas Sicking jo...@sicking.cc wrote:
style scoped should (I think) have three cases:
1. Selector without :scope - same as .find
2. Selector with :scope - Same as #1, but also including the context
node.
3. Selector in @global - run the selector across
On 20/10/11 1:07 PM, Jonas Sicking wrote:
On Tue, Oct 18, 2011 at 9:42 AM, Alex Russellslightly...@google.com wrote:
Lachlan and I have been having an...um...*spirited* twitter discussion
regarding querySelectorAll, the (deceased?) queryScopedSelectorAll,
and :scope. He asked me to continue
On Thu, Oct 20, 2011 at 1:14 AM, Sean Hogan shogu...@westnet.com.au wrote:
On 20/10/11 1:07 PM, Jonas Sicking wrote:
On Tue, Oct 18, 2011 at 9:42 AM, Alex Russellslightly...@google.com
wrote:
Lachlan and I have been having an...um...*spirited* twitter discussion
regarding querySelectorAll,
On 20/10/11 7:32 PM, Jonas Sicking wrote:
On Thu, Oct 20, 2011 at 1:14 AM, Sean Hoganshogu...@westnet.com.au wrote:
On 20/10/11 1:07 PM, Jonas Sicking wrote:
On Tue, Oct 18, 2011 at 9:42 AM, Alex Russellslightly...@google.com
wrote:
Lachlan and I have been having an...um...*spirited*
On Thu, Oct 20, 2011 at 2:13 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
On 2011-10-20 07:52, Jonas Sicking wrote:
I'm not sure I understand what you are proposing here. Are you saying that
div
style scoped
:scope {
background: green;
}
/style
/div
should set the background of
On 20/10/11 8:42 PM, Lachlan Hunt wrote:
On 2011-10-20 10:14, Sean Hogan wrote:
The primary use-case for matchesSelector() has been event-delegation,
and this is the same for matches(). More specifically, consider the
following scenario:
jQuery adds a new event registration method that uses
On Wed, Oct 19, 2011 at 7:01 PM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
On 2011-10-19 16:08, Alex Russell wrote:
On Wed, Oct 19, 2011 at 1:54 PM, Lachlan Huntlachlan.h...@lachy.id.au
wrote:
I have attempted to address this problem before and the algorithm for
parsing a *scoped
On Thu, Oct 20, 2011 at 3:07 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Oct 18, 2011 at 9:42 AM, Alex Russell slightly...@google.com wrote:
Lachlan and I have been having an...um...*spirited* twitter discussion
regarding querySelectorAll, the (deceased?) queryScopedSelectorAll,
and
On Thu, Oct 20, 2011 at 6:55 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Oct 18, 2011 at 9:42 AM, Alex Russell slightly...@google.com wrote:
Lachlan and I have been having an...um...*spirited* twitter discussion
regarding querySelectorAll, the (deceased?) queryScopedSelectorAll,
and
On 2011-10-20 12:50, Alex Russell wrote:
On Thu, Oct 20, 2011 at 6:55 AM, Jonas Sickingjo...@sicking.cc wrote:
Oh, and as a separate issue. I think .findAll should return a plain
old JS Array. Not a NodeList or any other type of host object.
I strongly agree that it should be an Array
On Thu, Oct 20, 2011 at 12:05 PM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
On 2011-10-20 12:50, Alex Russell wrote:
On Thu, Oct 20, 2011 at 6:55 AM, Jonas Sickingjo...@sicking.cc wrote:
Oh, and as a separate issue. I think .findAll should return a plain
old JS Array. Not a NodeList or
On 20/10/11 10:05 PM, Lachlan Hunt wrote:
On 2011-10-20 12:50, Alex Russell wrote:
On Thu, Oct 20, 2011 at 6:55 AM, Jonas Sickingjo...@sicking.cc wrote:
Oh, and as a separate issue. I think .findAll should return a plain
old JS Array. Not a NodeList or any other type of host object.
I
On 2011-10-20 13:18, Alex Russell wrote:
On Thu, Oct 20, 2011 at 12:05 PM, Lachlan Huntlachlan.h...@lachy.id.au wrote:
We need NodeList separate from Array where they are live lists.
No we don't. The fact that there's someone else who has a handle to
the list and can mutate it underneath you
On Thu, Oct 20, 2011 at 3:39 AM, Alex Russell slightly...@google.com wrote:
There's a corner case I haven't formed an opinion on though:
el.find(div span :scope .whatevs);
...does what? I think it's an error. :scope will need to occur in
the first term or not at all for .find().
Disagree.
On 2011-10-20 13:35, Sean Hogan wrote:
I wonder if anyone is relying on querySelectorAll() returning a
StaticNodeList?
Only if there are people out there using list.item(n) instead of
list[n], or people extending the NodeList interface and expecting such
methods to be available on the
On 20/10/11 10:49 PM, Lachlan Hunt wrote:
On 2011-10-20 13:35, Sean Hogan wrote:
I wonder if anyone is relying on querySelectorAll() returning a
StaticNodeList?
Only if there are people out there using list.item(n) instead of
list[n], or people extending the NodeList interface and expecting
On 10/20/11 6:50 AM, Alex Russell wrote:
Oh, and as a separate issue. I think .findAll should return a plain
old JS Array. Not a NodeList or any other type of host object.
I strongly agree that it should be an Array *type*, but I think just
returning a plain Array is the wrong resolution to
On 10/20/11 7:18 AM, Alex Russell wrote:
No we don't. The fact that there's someone else who has a handle to
the list and can mutate it underneath you
There is no sane way to mutate the list on the part of the browser if
someone else is also messing with it, because the someone else can
On Thu, Oct 20, 2011 at 3:14 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/20/11 7:18 AM, Alex Russell wrote:
No we don't. The fact that there's someone else who has a handle to
the list and can mutate it underneath you
There is no sane way to mutate the list on the part of the browser if
On 10/20/11 10:23 AM, Alex Russell wrote:
On Thu, Oct 20, 2011 at 3:14 PM, Boris Zbarskybzbar...@mit.edu wrote:
Right. So you need to vend an apparently-immutable Array, one which
can only be changed by the browser. I think that could be accomplished
in terms of Proxies. But it's still an Array
On 2011-10-20 16:23, Boris Zbarsky wrote:
On 10/20/11 1:08 AM, Tab Atkins Jr. wrote:
I disagree. It's extremely useful and natural for .find(:scope +
div) to match sibling of the context node.
I really don't think it is. If you want that, use document.find(:scope
+ div, context).
Basically,
On Thu, Oct 20, 2011 at 04:18, Alex Russell slightly...@google.com wrote:
No we don't. The fact that there's someone else who has a handle to
the list and can mutate it underneath you is a documentation issue,
not a question of type...unless the argument is that the slots should
be
On Thu, Oct 20, 2011 at 04:37, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
On 2011-10-20 13:18, Alex Russell wrote:
On Thu, Oct 20, 2011 at 12:05 PM, Lachlan Huntlachlan.h...@lachy.id.au
wrote:
We need NodeList separate from Array where they are live lists.
No we don't. The fact that
On Thu, Oct 20, 2011 at 04:49, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
On 2011-10-20 13:35, Sean Hogan wrote:
I wonder if anyone is relying on querySelectorAll() returning a
StaticNodeList?
Only if there are people out there using list.item(n) instead of list[n], or
people extending
On 10/20/11 12:02 PM, Erik Arvidsson wrote:
That is an ES violation. A non configurable, non writable data
property is not allowed to change its value.
It's not clear what that means in proxy-land; esp. since it's not clear
whether proxies can even have non-configurable properties... or did
On Thu, Oct 20, 2011 at 09:28, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/20/11 12:02 PM, Erik Arvidsson wrote:
That is an ES violation. A non configurable, non writable data
property is not allowed to change its value.
It's not clear what that means in proxy-land; esp. since it's not clear
On Thu, Oct 20, 2011 at 3:46 AM, Alex Russell slightly...@google.com wrote:
However, it does seem like selectors are here to stay. And as much as
they have shortcomings, people seem to really like them for querying.
So with that out of the way, I agree that the CSS working group
shouldn't be
On Thu, Oct 20, 2011 at 3:50 AM, Alex Russell slightly...@google.com wrote:
On Thu, Oct 20, 2011 at 6:55 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Oct 18, 2011 at 9:42 AM, Alex Russell slightly...@google.com wrote:
Lachlan and I have been having an...um...*spirited* twitter discussion
On Thu, Oct 20, 2011 at 7:23 AM, Alex Russell slightly...@google.com wrote:
On Thu, Oct 20, 2011 at 3:14 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/20/11 7:18 AM, Alex Russell wrote:
No we don't. The fact that there's someone else who has a handle to
the list and can mutate it underneath
On Thu, Oct 20, 2011 at 7:23 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/20/11 1:08 AM, Tab Atkins Jr. wrote:
I disagree. It's extremely useful and natural for .find(:scope +
div) to match sibling of the context node.
I really don't think it is. If you want that, use
On Thu, Oct 20, 2011 at 12:09 PM, Jonas Sicking jo...@sicking.cc wrote:
Let's do the general discussion about how live and non-live NodeLists
should behave in a separate thread.
Yes, let's. ^_^
The immediate question here is how should the returned object from
.findAll behave? Should it be
* Alex Russell wrote:
I strongly agree that it should be an Array *type*, but I think just
returning a plain Array is the wrong resolution to our NodeList
problem. WebIDL should specify that DOM List types *are* Array types.
It's insane that we even have a NodeList type which isn't a real array
at
On 10/20/11 4:32 PM, Tab Atkins Jr. wrote:
I don't really see the performance issues. If you use + or ~ off of
:scope, you know for a fact that all the nodes come *after* any
selectors that don't have :scope.
Yes.
1. Run the :scope-carrying selectors across the document together,
On Thu, Oct 20, 2011 at 2:04 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/20/11 4:32 PM, Tab Atkins Jr. wrote:
1. Run the :scope-carrying selectors across the document together,
automatically yielding a dom-ordered list.
2. Run the :scope-absent selectors together, automatically yielding a
On 2011-10-20 22:32, Tab Atkins Jr. wrote:
On Thu, Oct 20, 2011 at 7:23 AM, Boris Zbarskybzbar...@mit.edu wrote:
On 10/20/11 1:08 AM, Tab Atkins Jr. wrote:
Basically, the presence of :scope would turn off *all* the limitations
That's a _really_ bizarre behavior. So in this case:
On Thu, Oct 20, 2011 at 2:33 PM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
On 2011-10-20 22:32, Tab Atkins Jr. wrote:
On Thu, Oct 20, 2011 at 7:23 AM, Boris Zbarskybzbar...@mit.edu wrote:
On 10/20/11 1:08 AM, Tab Atkins Jr. wrote:
Basically, the presence of :scope would turn off *all*
On 10/20/11 5:15 PM, Tab Atkins Jr. wrote:
If they *all* carry :scope, then you can just run them all over the
whole tree and get the ordered set in the normal fashion.
You can just prepend :scope to the ones missing it and run them over the
whole tree too.
But that means that now you're
On Wed, Oct 19, 2011 at 2:26 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/18/11 8:08 PM, Alex Russell wrote:
The other excuse is that adding special cases (which is what you're
asking
for) slows down all the non-special-case codepaths. That may be fine for
_your_ usage of
On Wed, Oct 19, 2011 at 4:39 AM, Ojan Vafai o...@chromium.org wrote:
Overall, I wholeheartedly support the proposal.
I don't really see the benefit of allowing starting with a combinator. I
think it's a rare case that you actually care about the scope element and in
those cases, using :scope
On Wed, 19 Oct 2011 17:22:46 +0900, Alex Russell slightly...@google.com
wrote:
Yehuda is representing jQuery. I'll take his opinion as the global
view unless he choses to say he's representing a personal opinion.
You misunderstand. Boris is contrasting with CSS. Selectors are used in
more
Yehuda Katz
(ph) 718.877.1325
On Wed, Oct 19, 2011 at 1:22 AM, Alex Russell slightly...@google.comwrote:
On Wed, Oct 19, 2011 at 2:26 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/18/11 8:08 PM, Alex Russell wrote:
The other excuse is that adding special cases (which is what you're
On Wed, Oct 19, 2011 at 9:29 AM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 19 Oct 2011 17:22:46 +0900, Alex Russell slightly...@google.com
wrote:
Yehuda is representing jQuery. I'll take his opinion as the global
view unless he choses to say he's representing a personal opinion.
You
On 19/10/11 2:39 PM, Ojan Vafai wrote:
Overall, I wholeheartedly support the proposal.
I don't really see the benefit of allowing starting with a combinator.
I think it's a rare case that you actually care about the scope
element and in those cases, using :scope is fine. Instead of
On 2011-10-19 01:58, Tab Atkins Jr. wrote:
Based on discussion on the mailing list,style scoped will be
changing to the latter behavior as well, with the ability to invoke
the former behavior in the rare circumstances when you explicitly want
it.
Despite some similarities in appearance, the
On 2011-10-18 18:42, Alex Russell wrote:
Related and equally important, that querySelector and querySelectorAll
are often referred to by the abbreviation QSA suggests that its name
is bloated and improved versions should have shorter names.
I know the names suck. The names we ended up with
On Wed, Oct 19, 2011 at 1:54 PM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
On 2011-10-18 18:42, Alex Russell wrote:
Related and equally important, that querySelector and querySelectorAll
are often referred to by the abbreviation QSA suggests that its name
is bloated and improved versions
On 10/19/11 4:22 AM, Alex Russell wrote:
Yehuda is representing jQuery. I'll take his opinion as the global
view unless he choses to say he's representing a personal opinion.
Global jQuery view, yes? I stand by a slightly statement that what is
common and needs to be fast for Yehuda may not
On 10/19/11 4:29 AM, Anne van Kesteren wrote:
On Wed, 19 Oct 2011 17:22:46 +0900, Alex Russell
slightly...@google.com wrote:
Yehuda is representing jQuery. I'll take his opinion as the global
view unless he choses to say he's representing a personal opinion.
You misunderstand. Boris is
On 10/19/11 11:17 AM, Boris Zbarsky wrote:
4) Mapping Sizzle(#id) with document a context to
getElementById(id). This isn't a valid optimization for querySelector
because there can be multiple elements with the same id;
And just as a note, since someone asked me off-list how this can
possibly
On 2011-10-19 16:08, Alex Russell wrote:
On Wed, Oct 19, 2011 at 1:54 PM, Lachlan Huntlachlan.h...@lachy.id.au wrote:
I have attempted to address this problem before and the algorithm for
parsing a *scoped selector string* (basically what you're calling a
rootedSelector) existed in an old
On 2011-10-18 18:42, Alex Russell wrote:
HTMLDocument.prototype.find =
HTMLElement.prototype.find = function(rootedSelector) {
return this.querySelector(:scope + rootedSelector);
}
HTMLDocument.prototype.findAll =
HTMLElement.prototype.findAll = function(rootedSelector)
1 - 100 of 130 matches
Mail list logo
