Boris Zbarsky wrote:
That answers my complaint, but not my question: what is
queryScopedSelector supposed to do?
When it was originally added, it was supposed to handle all of the
pre-parsing of the selector to prepend :scope to each selector in the
group, including handling things like div,
On 1/11/10 12:13 PM, Boris Zbarsky wrote:
I do wonder how useful queryScopedSelector is, since it can be
implemented easily via querySelector...
I guess the main value is in fact in situations when one is given a
selector string already and not in situations where one is writing one's
own
either. However, keep in mind, I'd prefer to avoid having this
turn into another naming debate. Selectors API has suffered enough in
the past as a result of that.
So if you have anything more to add, I'd request that you check the
archives for this list and www-style for messages relating
, but that name wasn't
particularly well received either. However, keep in mind, I'd prefer
to avoid having this turn into another naming debate. Selectors API
has suffered enough in the past as a result of that.
So if you have anything more to add, I'd request that you check the
archives for this list
On 8/01/10 1:19 AM, Lachlan Hunt wrote:
Hi,
Now that Selectors API Level 1 is published and basically all but
finalised (just waiting for some implementations to be officially
released before taking it to REC), can we publish Selectors API Level
2 as an FPWD?
It would be useful to have
Sean Hogan wrote:
On 8/01/10 1:19 AM, Lachlan Hunt wrote:
can we publish Selectors API Level 2 as an FPWD?
http://dev.w3.org/2006/webapi/selectors-api2/
FYI, it seems the whole Status of this Document hasn't been updated for
Selectors-API2.
Yeah, that will get fixed up when I get the spec
On 11/01/10 8:29 AM, Lachlan Hunt wrote:
Sean Hogan wrote:
On 8/01/10 1:19 AM, Lachlan Hunt wrote:
can we publish Selectors API Level 2 as an FPWD?
http://dev.w3.org/2006/webapi/selectors-api2/
I can't see the value of queryScopedSelector*() methods. The original
rationale was that JS
differently from the v1 Selectors API. In
particular, if I understand correctly, the behavior of:
element.querySelector(body div)
in matching all divs that are descendants of |element| and also
descendants of a body (which may be an _ancestor_ of |element|) is
different from the selector
scoped in
the sense that they behave differently from the v1 Selectors API. In
particular, if I understand correctly, the behavior of:
element.querySelector(body div)
in matching all divs that are descendants of |element| and also
descendants of a body (which may be an _ancestor_
it, jquery selectors on elements are always scoped in
the sense that they behave differently from the v1 Selectors API. In
particular, if I understand correctly, the behavior of:
element.querySelector(body div)
in matching all divs that are descendants of |element| and also
descendants
On 1/11/10 1:24 AM, Sean Hogan wrote:
That's correct. jQuery's $(element).find(div) is the equivalent of
SelectorsAPI2's element.querySelectorAll(:scope div) or
So in fact jquery can simply implement Element.find in terms of
querySelectorAll by just prepending :scope to the selector string,
This is a Call for Consensus (CfC) to publish the First Public
Working Draft (FPWD) of the Selectors API Level 2 spec:
http://dev.w3.org/2006/webapi/selectors-api2/
This CfC satisfies the group's requirement to record the group's
decision to request advancement.
By publishing this FPWD
I support this publication.
On Sat, Jan 9, 2010 at 5:56 AM, Arthur Barstow art.bars...@nokia.com wrote:
This is a Call for Consensus (CfC) to publish the First Public Working Draft
(FPWD) of the Selectors API Level 2 spec:
http://dev.w3.org/2006/webapi/selectors-api2/
This CfC satisfies
I support this publication.
- Maciej
On Jan 9, 2010, at 5:56 AM, Arthur Barstow wrote:
This is a Call for Consensus (CfC) to publish the First Public
Working Draft (FPWD) of the Selectors API Level 2 spec:
http://dev.w3.org/2006/webapi/selectors-api2/
This CfC satisfies the group's
Hi,
Now that Selectors API Level 1 is published and basically all but
finalised (just waiting for some implementations to be officially
released before taking it to REC), can we publish Selectors API Level 2
as an FPWD?
It would be useful to have it more widely reviewed, especially since
On Thu, 19 Nov 2009 00:49:58 +0100, Charles McCathieNevile
cha...@opera.com wrote:
Hi folks,
this is a Call for consensus to request publishing the Selectors API
draft at
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?rev=1.101content-type=text/html
a solution to a problem that does not
exist.
That's because you're not reading what Jonathan has been saying. He said xml:id
was just the example that drew his attention to the fact that the selectors API
can't do namespaces. He points out, rather correctly, that there is no reason
that Web
to find a solution to a problem that
does not exist.
That's because you're not reading what Jonathan has been saying. He
said xml:id was just the example that drew his attention to the fact
that the selectors API can't do namespaces.
Yes, I know what he said. The point is that since he agrees
sites are switching from selectors api to xpath
for the namespace support, or using some other work around, that would go a
long way towards understanding what the use cases are, and what problems
really need to be solved, as well as help in determining whether or not the
problems
.
Besides, all of those APIs mentioned also offer JSON output, which is
much more optimised for use in JavaScript environments where cross site
requests will be most common.
So what other sorts of APIs do you have in mind which would greatly
benefit from namespace support in selectors API? It would
On Thu, 26 Nov 2009, Anne van Kesteren wrote:
The CSS WG relatively recently dropped this requirement. Developer
builds are now sufficient. I was not really in favor, but most of the
group was.
I'm not really in favour of dropping this requirements either. The whole
point of beta builds
On Nov 26, 2009, at 13:18, Jonathan Watt wrote:
During a discussion about xml:id I was about to make the throw away comment
that
you could use querySelector to easily work around lack of support for xml:id,
but on checking it turns out that's not the case. querySelector, it seems,
cannot be
On Thu, 26 Nov 2009 09:33:28 -0200, Henri Sivonen hsivo...@iki.fi wrote:
On Nov 26, 2009, at 13:18, Jonathan Watt wrote:
[...]
Isn't the easiest solution not to support xml:id on the Web? It's not
supported in Gecko, WebKit or Trident. What's the upside of adding it?
Besides that,
Jonathan Watt wrote:
During a discussion about xml:id I was about to make the throw away comment that
you could use querySelector to easily work around lack of support for xml:id,
but on checking it turns out that's not the case. querySelector, it seems,
cannot be used to select on a specific
On 2009-11-26 12:33 PM, Henri Sivonen wrote:
On Nov 26, 2009, at 13:18, Jonathan Watt wrote:
During a discussion about xml:id I was about to make the throw away comment
that
you could use querySelector to easily work around lack of support for xml:id,
but on checking it turns out that's
On 2009-11-26 1:16 PM, Lachlan Hunt wrote:
Jonathan Watt wrote:
Maybe the working group could consider adding some sort of non-prefix
namespace support to selectors for the sake of
querySelector/querySelectorsAll,
something like:
[url(http://www.w3.org/XML/1998/namespace;)|id=foo]
On 2009-11-26 2:16 PM, Jonathan Watt wrote:
On 2009-11-26 1:16 PM, Lachlan Hunt wrote:
Jonathan Watt wrote:
Maybe the working group could consider adding some sort of non-prefix
namespace support to selectors for the sake of
querySelector/querySelectorsAll,
something like:
Maciej Stachowiak wrote:
The proposed exit criteria are in a separate thread, but essentially are:
For a set of tests based on HTML, CSS 2.1 selectors and this spec,
there are two implementations that pass every test interoperably, and
do not fail any additional tests based on misimplementing
Jonathan Watt wrote:
On 2009-11-26 12:33 PM, Henri Sivonen wrote:
On Nov 26, 2009, at 13:18, Jonathan Watt wrote:
During a discussion about xml:id I was about to make the throw away comment that
you could use querySelector to easily work around lack of support for xml:id,
but on checking it
Lachlan Hunt wrote:
There must be at least two complete, independent implementations, each
of which must pass 100% of the baseline testsuite and should pass
additional tests, dependent on the following conditions:
...
The current state of implementations is as follows:
Minefield:
Baseline
On Thu, 26 Nov 2009 15:58:56 +0100, Lachlan Hunt
lachlan.h...@lachy.id.au wrote:
Lachlan Hunt wrote:
There must be at least two complete, independent implementations, each
of which must pass 100% of the baseline testsuite and should pass
additional tests, dependent on the following
BlackBerry 9700 browser:
(Kartikaya Gupta from RIM e-mailed me off list about this to tell me,
I'm unable to verify these results myself without access to the
device.)
Baseline Tests: HTML/CSS2.1:PASS
Additional Tests: HTML/CSS3: PASS
Additional Tests:
On 11/26/09 9:58 AM, Lachlan Hunt wrote:
Actually, correction. Minefield and Opera don't meet the condition if we
keep the shipping requirement in the exit criteria.
Which imo we should. I don't think we want to be opening up that loophole.
The Gecko 1.9.2 branch builds have the
On 11/26/09 11:52 AM, Charles McCathieNevile wrote:
And I don't see any problem with using public development builds.
The main problem I have with them is that they have typically not gone
through the sort of full QA cycle that would point out possible problems
in the implementation of the
Boris Zbarsky wrote:
On 11/26/09 9:58 AM, Lachlan Hunt wrote:
Actually, correction. Minefield and Opera don't meet the condition if we
keep the shipping requirement in the exit criteria.
Which imo we should. I don't think we want to be opening up that loophole.
The Gecko 1.9.2 branch builds
On Thu, 26 Nov 2009 21:05:31 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/26/09 9:58 AM, Lachlan Hunt wrote:
Actually, correction. Minefield and Opera don't meet the condition if we
keep the shipping requirement in the exit criteria.
Which imo we should. I don't think we want to be
Lachlan Hunt wrote:
Maciej Stachowiak wrote:
The proposed exit criteria are in a separate thread, but essentially
are:
For a set of tests based on HTML, CSS 2.1 selectors and this spec,
there are two implementations that pass every test interoperably, and
do not fail any additional tests
/webapi/selectors-api-testsuite/
More progress has now been made, and each of those test files have been
updated and all bugs I'm aware of have been fixed.
I've also begun to add tests for the namespace selector syntax [2] to
the second set, but they are currently a work in progress
On Nov 18, 2009, at 6:49 PM, ext Charles McCathieNevile wrote:
this is a Call for consensus to request publishing the Selectors
API draft
at
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/
Overview.html?rev=1.101content-type=text/html;%20charset=iso-8859-1
as a Candidate
On Wed, Nov 18, 2009 at 3:49 PM, Charles McCathieNevile
cha...@opera.com wrote:
Hi folks,
this is a Call for consensus to request publishing the Selectors API draft
at
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?rev=1.101content-type=text/html;%20charset=iso
On Thu, 19 Nov 2009 00:49:58 +0100, Charles McCathieNevile
cha...@opera.com wrote:
Hi folks,
this is a Call for consensus to request publishing the Selectors API
draft at
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?rev=1.101content-type=text/html
On Nov 19, 2009, at 00:49 , Charles McCathieNevile wrote:
this is a Call for consensus to request publishing the Selectors API draft at
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?rev=1.101content-type=text/html;%20charset=iso-8859-1
as a Candidate
Hi folks,
this is a Call for consensus to request publishing the Selectors API draft
at
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?rev=1.101content-type=text/html;%20charset=iso-8859-1
as a Candidate Recommendation (assuming Lachy fixes the apparent
are required to have support for:
- Selectors API
- Selectors defined in CSS 2.1.
- HTML
* Tested implementaions may optionally support:
- Selectors introduced in Selectors Level 3
- XHTML
- SVG
At least two implementations must pass 100% of the baseline testsuite
and should pass
Charles McCathieNevile wrote:
Hi folks,
this is a Call for consensus to request publishing the Selectors API
draft at
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?rev=1.101content-type=text/html;%20charset=iso-8859-1
as a Candidate Recommendation (assuming Lachy
Hi,
Since we didn't get much time to discuss selectors api 2 during TPAC,
this is an overview of the status, and a rough idea of how much work
needs to be done.
Please refer to the draft spec [1] and the issue list for features being
added [2].
The spec has a proposal to address a number
still like to see the test suite
updated, though; this draft hasn't been touched in a really long time,
and I don't think the selectors-api test suite should rely on it
excessively in its current state.
Something clearly needs to change; either the selectors API test suite
along with some
Lachlan Hunt wrote:
John Resig wrote:
With that in mind, option #3 looks the best to me. It's lame that the
API
will be longer but we'll be able to use basic object detection to see
if it
exists. Unfortunately the proper scoping wasn't done the first time the
Selectors API was implemented so
Garrett Smith wrote:
On Thu, Sep 24, 2009 at 1:28 AM, Lachlan Huntlachlan.h...@lachy.id.au wrote:
And overload the querySelector() and querySelectorAll() methods to also
accept a Selector object as the selector parameter.
createSelector would allow the browser to parse and compile the
On Mon, Sep 28, 2009 at 2:31 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
Garrett Smith wrote:
On Thu, Sep 24, 2009 at 1:28 AM, Lachlan Huntlachlan.h...@lachy.id.au
wrote:
And overload the querySelector() and querySelectorAll() methods to also
accept a Selector object as the selector
Boris Zbarsky wrote:
On 9/26/09 4:36 PM, Lachlan Hunt wrote:
A scoped selector string is a string that begins with an exclamation
point followed by a the remainder of the selector.
This assumes that '!' will never be allowed at the beginning of a CSS
selector, right?
It does, but the
wasn't done the first time the
Selectors API was implemented so we kind of have to play the hand we've been
dealt.
Thus there would be two new methods:
queryScopedSelectorAll
queryScopedSelector
I really didn't want to introduce new methods for this if it could be
avoided. I realise one problem
On 9/26/09 4:36 PM, Lachlan Hunt wrote:
A scoped selector string is a string that begins with an exclamation
point followed by a the remainder of the selector.
This assumes that '!' will never be allowed at the beginning of a CSS
selector, right? Have you run this by the CSS working group?
Hi Lachy,
Here's a proposal.
querySelector*(selector, context) // allows selectors with :scope
pseudo-class
queryScopedSelector*(selector, context) // allows selectors with implied
:scope
matchesSelector(selector, context) // allows selectors with :scope
pseudo-class
To check if the :scope
Sean Hogan wrote:
Hi Lachy,
Here's a proposal.
querySelector*(selector, context) // allows selectors with :scope
pseudo-class
queryScopedSelector*(selector, context) // allows selectors with
implied :scope
matchesSelector(selector, context) // allows selectors with :scope
pseudo-class
To
my least favourite solution of them all.
2. I think :context is a better name than :scope
Yeah, the name of :scope is a complicated issue. :context isn't ideal
either. It would be slightly confusing because selectors API defines
the term context node as being the node upon which the method
a webidl
question, not a selectors API question, is what makes something an
element, array, or nodelist. First off, what if some spec introduces
objects that implement both the Element and NodeList interfaces?
Second, what if I do:
function foo() {
}
foo.prototype = Array.prototype
var
On 9/25/09 1:35 AM, Garrett Smith wrote:
No, you did not say it is slow. I'm saying that your laptop is
probably a lot more powerful than a mobile device with a browser, such
as Blackberry9000. Do you agree with that?
Sure. It's a pretty self-evidently true claim.
that said, note that on a
case of .matchesSelector( div) doesn't really exist.
With that in mind, option #3 looks the best to me. It's lame that the API
will be longer but we'll be able to use basic object detection to see if it
exists. Unfortunately the proper scoping wasn't done the first time the
Selectors API
is a better name than :scope
Yeah, the name of :scope is a complicated issue. :context isn't ideal
either. It would be slightly confusing because selectors API defines
the term context node as being the node upon which the method is
being invoked. Maybe something like :ref or :reference might work
On Wed, Sep 23, 2009 at 9:57 PM, Maciej Stachowiak m...@apple.com wrote:
On Sep 23, 2009, at 5:26 PM, Jonas Sicking wrote:
On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt lachlan.h...@lachy.id.au
wrote:
*Scoped Queries*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860
This has been
Yes, the base for event delegation is certainly something
like that. I just wanted to make clear that the main reason
for adding this functionality (IMO) is event delegation.
I'll let event delegation library creators chime in on the
details on what is needed for making really efficient
Sean Hogan wrote:
I think a couple of those features are pretty low priority:
- I don't see the point of collective queries on NodeLists.
Are there any references for the proposal?
Otherwise I can't think of any useful queries that can't already be
achieved with a single querySelectorAll().
On Thu, Sep 24, 2009 at 12:02 AM, Mike Wilson mike...@hotmail.com wrote:
Yes, the base for event delegation is certainly something
like that. I just wanted to make clear that the main reason
for adding this functionality (IMO) is event delegation.
I'll let event delegation library creators
Lachlan Hunt wrote:
Sean Hogan wrote:
I think a couple of those features are pretty low priority:
- I don't see the point of collective queries on NodeLists.
Are there any references for the proposal?
Otherwise I can't think of any useful queries that can't already be
achieved with a single
Garrett Smith wrote:
QuerySelector could be extended to have properties:
readonly attribute boolean valid
StaticNodeList match(in HTMLElement contextNode)
What's the valid property for? It seems redundant. If the selector
isn't valid, then the factory method should throw an error when
Garrett Smith wrote:
On Thu, Sep 24, 2009 at 12:02 AM, Mike Wilson mike...@hotmail.com wrote:
Yes, the base for event delegation is certainly something
like that. I just wanted to make clear that the main reason
for adding this functionality (IMO) is event delegation.
I'll let event
Lachlan Hunt wrote:
Lachlan Hunt wrote:
Sean Hogan wrote:
I think a couple of those features are pretty low priority:
- I don't see the point of collective queries on NodeLists.
Are there any references for the proposal?
Otherwise I can't think of any useful queries that can't already be
be removed from the collection.
So the question is, at which point in the chain do you want to address
this issue? The options are:
A) Have specific selectors API feauture that allowed executing a
selector query on a whole collection of elements that returns a
single, sorted collection
Sean Hogan wrote:
http://krijnhoetmer.nl/irc-logs/whatwg/20090922#l-
I couldn't see where it was needed, only that it was possible in jQuery.
I still can't think of any NodeLists that this could usefully be applied
to that couldn't be achieved with a single querySelectorAll(). At least
So the question is, at which point in the chain do you want to address
this issue? The options are:
A) Have specific selectors API feauture that allowed executing a
selector query on a whole collection of elements that returns a
single, sorted collection of unique elements.
B
John Resig wrote:
So the question is, at which point in the chain do you want to address
this issue? The options are:
A) Have specific selectors API feauture that allowed executing a
selector query on a whole collection of elements that returns a
single, sorted collection of unique
On Thu, Sep 24, 2009 at 6:06 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/24/09 6:29 AM, Sean Hogan wrote:
I would be surprised if an implementation didn't create an internal
lookup table keyed off the selector text.
Gecko doesn't. Webkit doesn't.
I just checked really quickly, and on
On Sep 23, 2009, at 8:37 PM, Jonas Sicking wrote:
On Wed, Sep 23, 2009 at 8:17 PM, John Resig jere...@gmail.com wrote:
Quick Summary of my opinions:
Matches Selector: Super-super useful - critical, in fact. We're not
able to
remove jQuery's selector engine until this is implemented. I'm
On 9/24/09 2:17 PM, Garrett Smith wrote:
On Thu, Sep 24, 2009 at 6:06 AM, Boris Zbarskybzbar...@mit.edu wrote:
Gecko doesn't. Webkit doesn't.
I just checked really quickly, and on my machine (a year-plus old laptop)
That is probably many times faster, and can probably be much more
liberal,
On 9/24/09 2:36 PM, Sam Weinig wrote:
WebKit now also has an implementation of Element.matchesSelector() (we
are calling ours webkitMatchesSelector for the time being).
[https://bugs.webkit.org/show_bug.cgi?id=29703]
Right. The Gecko one is mozMatchesSelector.
I bet we'd both love to rename
of the divs. This
is not something that I would expect the Selectors API to support but the
case of merging those results, sorting them, and uniqueing them is taking
place and is very costly.
To explain what I mean, let's look at a simple DOM:
html
body
div id=one
div id=two/div
/div
On Sep 24, 2009, at 11:39 AM, Boris Zbarsky wrote:
On 9/24/09 2:36 PM, Sam Weinig wrote:
WebKit now also has an implementation of Element.matchesSelector()
(we
are calling ours webkitMatchesSelector for the time being).
[https://bugs.webkit.org/show_bug.cgi?id=29703]
Right. The Gecko one
On Thu, Sep 24, 2009 at 11:21 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
It would be great to have a separate, standalone, function that handles
these merge/sort/unique operations for collections of DOM elements
(especially if they're disconnected from the document!).
The proposal from
On Thu, Sep 24, 2009 at 8:59 AM, John Resig jre...@mozilla.com wrote:
Another alternative
would be to implement the merge/sort/unique method and have it return a
NodeList (which would, then, have qSA).
For example:
document.createNodeList([ ... some elements ... ]).querySelectorAll(em,
My concern with this API is that it forces the implementation to
always sort the array, even if already sorted, and then do a merge
sort on the individual results from querySelectorAll. It would be
faster to simply run the query on each node, and then merge sort the
results.
That's not a
On 9/24/09 5:09 PM, John Resig wrote:
It's only if it's an array that we have to do the dance. Even in the
case where the array of results is already in document order the sort
will be incredibly fast (O(N)).
O(N) in number of nodes in the array, and that assumes that the array is
not being
On Thu, Sep 24, 2009 at 2:09 PM, John Resig jre...@mozilla.com wrote:
My concern with this API is that it forces the implementation to
always sort the array, even if already sorted, and then do a merge
sort on the individual results from querySelectorAll. It would be
faster to simply run the
On Thu, Sep 24, 2009 at 2:41 PM, Jonas Sicking jo...@sicking.cc wrote:
If this is how it's implemented it actually becomes really useful to
have
the NodeList-based element filtering.
document.createNodeList([ ... some elements ...
]).filterSelector(em,
strong)
(Since this
is comparable, though I can't
tell how much of their time is selector parsing.
That is surprising. Does the CSS engine do the same? If the CSS engine
doesn't store the parsed selector then it probably doesn't matter for JS
calls either.
If you're doing less than 1,000 calls that involve selectors api
Lachlan Hunt wrote:
Mike Wilson wrote:
My first priority would be Matches Selector, and see to that
it fulfills the needs for event delegation.
Is there any special functionality that would be needed to achieve
this? If I understand correctly, event delegation just needs to be
able to
On 9/24/09 6:45 PM, Sean Hogan wrote:
That is surprising. Does the CSS engine do the same? If the CSS engine
doesn't store the parsed selector then it probably doesn't matter for JS
calls either.
In Gecko the CSS engine stores the parsed selector. In addition, it
stores the selectors in
Boris Zbarsky wrote:
On 9/24/09 6:45 PM, Sean Hogan wrote:
That is surprising. Does the CSS engine do the same? If the CSS engine
doesn't store the parsed selector then it probably doesn't matter for JS
calls either.
In Gecko the CSS engine stores the parsed selector. In addition, it
stores
Hi,
I have checked in the first copy of Selectors API Level 2, and have
defined the matchesSelector() API.
http://dev.w3.org/2006/webapi/selectors-api2/#matchtesting
Everything else in the spec is currently identical to level 1. I had to
do some minor shuffling around to make things
Hi,
I'm trying to find a suitable solution for the scoped selector
issues, but figuring out what the most suitable API is proving challenging.
*Use Cases*
1. JS libraries like JQuery and others, accept special selector strings
beginning with combinators. e.g. em,+strong. These libraries
On Thu, Sep 24, 2009 at 11:38 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/24/09 2:17 PM, Garrett Smith wrote:
On Thu, Sep 24, 2009 at 6:06 AM, Boris Zbarskybzbar...@mit.edu wrote:
Gecko doesn't. Webkit doesn't.
I just checked really quickly, and on my machine (a year-plus old laptop)
Hi,
I'm planning to look at beginning work on Selectors API v2 soon to
add a number of requested features that didn't make it into the first
version. This e-mail is a summary of what is being considered, and is
intended to start discussion about which ones are really worth focussing
My first priority would be Matches Selector, and see to that
it fulfills the needs for event delegation.
Best regards
Mike Wilson
Lachlan Hunt wrote:
Hi,
I'm planning to look at beginning work on Selectors API v2 soon to
add a number of requested features that didn't make
Mike Wilson wrote:
My first priority would be Matches Selector, and see to that
it fulfills the needs for event delegation.
Is there any special functionality that would be needed to achieve this?
If I understand correctly, event delegation just needs to be able to
check whether the event
On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
*Scoped Queries*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860
This has been discussed extensively in the past. Basically, the idea is
that the selector would be evaluated in the scope of the element, in a way
Jonas Sicking wrote:
On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
*Scoped Queries*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860
This has been discussed extensively in the past. Basically, the idea is
that the selector would be evaluated in the scope
NodeLists is trivial once we get matchesSelector().
Sean
Lachlan Hunt wrote:
Hi,
I'm planning to look at beginning work on Selectors API v2 soon to
add a number of requested features that didn't make it into the first
version. This e-mail is a summary of what is being considered
On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
Hi,
I'm planning to look at beginning work on Selectors API v2 soon to add a
number of requested features that didn't make it into the first version.
This e-mail is a summary of what is being considered
and fallback to the old
selector engine.
Namespace Prefix Resolution: Indifferent.
--John
On Wed, Sep 23, 2009 at 7:51 AM, Lachlan Hunt lachlan.h...@lachy.id.auwrote:
Hi,
I'm planning to look at beginning work on Selectors API v2 soon to add a
number of requested features that didn't make
On Wed, Sep 23, 2009 at 8:17 PM, John Resig jere...@gmail.com wrote:
Quick Summary of my opinions:
Matches Selector: Super-super useful - critical, in fact. We're not able to
remove jQuery's selector engine until this is implemented. I'm working with
the devs at Mozilla to get an
201 - 300 of 496 matches
Mail list logo
