On 26/11/11 12:00 AM, Lachlan Hunt wrote:
On 2011-11-25 00:19, Sean Hogan wrote:
This has been raised before, but I'll restate it here.
How should the selector be expanded in
elt.findAll(div span, div :scope span)?
The implication of :scope has to be done on a per complex selector
basis,
On 25/11/11 6:49 PM, Lachlan Hunt wrote:
On 2011-11-25 01:07, Sean Hogan wrote:
On 24/11/11 7:46 PM, Lachlan Hunt wrote:
On 2011-11-23 23:38, Sean Hogan wrote:
- If you want to use selectors with :scope implied at the start of
each
selector in the selector list (as most js libs currently do)
All -
I'm going to throw my 2 cents in here and say that, whatever ends up happening
with scoping, that the equivalent of the current
querySelector()/querySelectorAll() should be named matchesSelector().
As a longtime Web developer (and trainer of other Web developers) it is
important to me
On 2011-11-23 23:38, Sean Hogan wrote:
Are there any issues with:
- If you want to use selectors with explicit :scope then you use
querySelector / querySelectorAll / matchesSelector.
- If you want to use selectors with :scope implied at the start of each
selector in the selector list (as most
On 2011-11-24 00:52, Yehuda Katz wrote:
On Wed, Nov 23, 2011 at 2:38 PM, Sean Hoganshogu...@westnet.com.au wrote:
The alternative option (find / findAll / matches can accept explicit
:scope, but will otherwise imply :scope) seems to be where all the
ambiguity lies.
What exact cases are
On Thu, Nov 24, 2011 at 12:50 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
On 2011-11-24 00:52, Yehuda Katz wrote:
On Wed, Nov 23, 2011 at 2:38 PM, Sean Hoganshogu...@westnet.com.au
wrote:
The alternative option (find / findAll / matches can accept explicit
:scope, but will otherwise
On 11/23/11 5:38 PM, Sean Hogan wrote:
- If you want to use selectors with :scope implied at the start of each
selector in the selector list (as most js libs currently do) then you
use find / findAll / matches.
I'm not sure that for matches() the :scope thing is all that relevant.
:matches()
Yehuda Katz
(ph) 718.877.1325
On Thu, Nov 24, 2011 at 9:47 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/23/11 5:38 PM, Sean Hogan wrote:
- If you want to use selectors with :scope implied at the start of each
selector in the selector list (as most js libs currently do) then you
use find
On 24/11/11 10:52 AM, Yehuda Katz wrote:
Yehuda Katz
(ph) 718.877.1325
On Wed, Nov 23, 2011 at 2:38 PM, Sean Hogan shogu...@westnet.com.au
mailto:shogu...@westnet.com.au wrote:
On 23/11/11 12:17 AM, Boris Zbarsky wrote:
On 11/22/11 6:50 AM, Lachlan Hunt wrote:
On 24/11/11 7:46 PM, Lachlan Hunt wrote:
On 2011-11-23 23:38, Sean Hogan wrote:
Are there any issues with:
- If you want to use selectors with explicit :scope then you use
querySelector / querySelectorAll / matchesSelector.
- If you want to use selectors with :scope implied at the start of
On Thu, Nov 24, 2011 at 3:19 PM, Sean Hogan shogu...@westnet.com.au wrote:
This has been raised before, but I'll restate it here.
How should the selector be expanded in
elt.findAll(div span, div :scope span)?
The straight-forward interpretation of implies :scope unless it is
explicit is
On 2011-11-25 01:07, Sean Hogan wrote:
On 24/11/11 7:46 PM, Lachlan Hunt wrote:
On 2011-11-23 23:38, Sean Hogan wrote:
- If you want to use selectors with :scope implied at the start of each
selector in the selector list (as most js libs currently do) then you
use find / findAll / matches.
On Tue, Nov 22, 2011 at 12:19 AM, Yehuda Katz wyc...@gmail.com wrote:
I like .is, the name jQuery uses for this purpose. Any reason not to go with
it?
We might want it for something else. .matches clearly sounds like
it's selector-related, and I have more trouble thinking of another
meaning
On Tue, Nov 22, 2011 at 1:04 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Again, some decent data on what pages actually do in on* handlers would be
really good. I have no idea how to get it. :(
Can't browsers add instrumentation for this? You have users who have
opted in to sending anonymized
On 11/23/11 10:03 AM, Aryeh Gregor wrote:
Can't browsers add instrumentation for this? You have users who have
opted in to sending anonymized data. So for each user, on a small
percentage of pages, intercept all bare-name property accesses in on*.
With enough work, this is possible. It'd
Works for me. I can live with .matches, but .matchesSelector is too verbose.
Yehuda Katz
(ph) 718.877.1325
On Wed, Nov 23, 2011 at 6:39 AM, Aryeh Gregor a...@aryeh.name wrote:
On Tue, Nov 22, 2011 at 12:19 AM, Yehuda Katz wyc...@gmail.com wrote:
I like .is, the name jQuery uses for this
On 23/11/11 12:17 AM, Boris Zbarsky wrote:
On 11/22/11 6:50 AM, Lachlan Hunt wrote:
Last time we had this discussion, you had a desire to keep the name
prefixed until the refNodes and :scope stuff was implemented [1]. What's
the status on that now?
The status is that I've given up on the
Yehuda Katz
(ph) 718.877.1325
On Wed, Nov 23, 2011 at 2:38 PM, Sean Hogan shogu...@westnet.com.au wrote:
On 23/11/11 12:17 AM, Boris Zbarsky wrote:
On 11/22/11 6:50 AM, Lachlan Hunt wrote:
Last time we had this discussion, you had a desire to keep the name
prefixed until the refNodes and
Yehuda Katz
(ph) 718.877.1325
On Tue, Nov 22, 2011 at 12:14 AM, Roland Steiner rolandstei...@chromium.org
wrote:
On Tue, Nov 22, 2011 at 14:19, Yehuda Katz wyc...@gmail.com wrote:
Yehuda Katz
(ph) 718.877.1325
On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On
On Tue, Nov 22, 2011 at 14:19, Yehuda Katz wyc...@gmail.com wrote:
Yehuda Katz
(ph) 718.877.1325
On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/21/11 11:31 AM, Tab Atkins Jr. wrote:
1) Make sense.
2) Not break existing content.
3) Be short.
.matches
On 22/11/11 7:14 PM, Roland Steiner wrote:
On Tue, Nov 22, 2011 at 14:19, Yehuda Katz wyc...@gmail.com
mailto:wyc...@gmail.com wrote:
Yehuda Katz
(ph) 718.877.1325 tel:718.877.1325
On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky bzbar...@mit.edu
mailto:bzbar...@mit.edu wrote:
On 11/22/11 1:56 AM, Sean Hogan wrote:
On 22/11/11 7:14 PM, Roland Steiner wrote:
On Tue, Nov 22, 2011 at 14:19, Yehuda Katz wyc...@gmail.com
mailto:wyc...@gmail.com wrote:
Yehuda Katz
(ph) 718.877.1325 tel:718.877.1325
On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky
Complexity and discussions about combinators seem to have prevented it from
getting into any draft despite lots of +1s. It is really different from
the rest of the selectors that exist today which are optimized like crazy
so it requires more in term of implementation than most to keep performance
On 11/22/11 6:50 AM, Lachlan Hunt wrote:
Last time we had this discussion, you had a desire to keep the name
prefixed until the refNodes and :scope stuff was implemented [1]. What's
the status on that now?
The status is that I've given up on the :scope discussion reaching a
conclusion in
On Tue, Nov 22, 2011 at 12:18 AM, Yehuda Katz wyc...@gmail.com wrote:
Yehuda Katz
(ph) 718.877.1325
On Tue, Nov 22, 2011 at 12:14 AM, Roland Steiner
rolandstei...@chromium.org wrote:
On Tue, Nov 22, 2011 at 14:19, Yehuda Katz wyc...@gmail.com wrote:
Yehuda Katz
(ph) 718.877.1325
On
+ian since this wording is actually in the HTML spec.
I'm not sure how exactly this should be specced. DOM4 could specify the two
interfaces and HTML could use those definitions?
On Mon, Nov 21, 2011 at 7:05 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/21/11 9:58 PM, Ojan Vafai wrote:
I
On 11/22/11 12:57 PM, Ojan Vafai wrote:
The fewer properties that are exposed this way, the smaller the quirk
is.
I think the problem is that from web developers point of view the quirky
behavior is _not_ exposing properties. Certainly in the short term...
In the long term, since we have
On Tue, Nov 22, 2011 at 10:04 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/22/11 12:57 PM, Ojan Vafai wrote:
The fewer properties that are exposed this way, the smaller the quirk
is.
I think the problem is that from web developers point of view the quirky
behavior is _not_ exposing
On Tue, Nov 22, 2011 at 10:24 AM, Ojan Vafai o...@chromium.org wrote:
On Tue, Nov 22, 2011 at 10:04 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/22/11 12:57 PM, Ojan Vafai wrote:
The fewer properties that are exposed this way, the smaller the quirk
is.
I think the problem is that from
On Tue, Nov 22, 2011 at 4:12 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Nov 22, 2011 at 10:24 AM, Ojan Vafai o...@chromium.org wrote:
On Tue, Nov 22, 2011 at 10:04 AM, Boris Zbarsky bzbar...@mit.edu
wrote:
On 11/22/11 12:57 PM, Ojan Vafai wrote:
I was hoping that we could have a
What's the current state of matchesSelector? Are we confident enough in
the name and such to unprefix it?
-Boris
On Mon, Nov 21, 2011 at 7:22 AM, Boris Zbarsky bzbar...@mit.edu wrote:
What's the current state of matchesSelector? Are we confident enough in the
name and such to unprefix it?
I think that matchesSelector suffers from the same verbosity that qSA
does, and would benefit from the same
On 11/21/11 10:56 AM, Tab Atkins Jr. wrote:
On Mon, Nov 21, 2011 at 7:22 AM, Boris Zbarskybzbar...@mit.edu wrote:
What's the current state of matchesSelector? Are we confident enough in the
name and such to unprefix it?
I think that matchesSelector suffers from the same verbosity that qSA
On Mon, Nov 21, 2011 at 8:23 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/21/11 10:56 AM, Tab Atkins Jr. wrote:
On Mon, Nov 21, 2011 at 7:22 AM, Boris Zbarskybzbar...@mit.edu wrote:
What's the current state of matchesSelector? Are we confident enough in
the
name and such to unprefix
On 11/21/11 11:31 AM, Tab Atkins Jr. wrote:
1) Make sense.
2) Not break existing content.
3) Be short.
.matches
.is
The sticking point here is obviously item #2. Data needed on use of
matches and is as barewords in on* attributes, specifically.
-Boris
On Mon, Nov 21, 2011 at 11:34 AM, Boris Zbarsky bzbar...@mit.edu wrote:
The sticking point here is obviously item #2. Data needed on use of
matches and is as barewords in on* attributes, specifically.
I don't follow. matchesSelector is on Element, not Node, right? Why
is it relevant to on*
On Mon, Nov 21, 2011 at 5:31 PM, Aryeh Gregor a...@aryeh.name wrote:
On Mon, Nov 21, 2011 at 11:34 AM, Boris Zbarsky bzbar...@mit.edu wrote:
The sticking point here is obviously item #2. Data needed on use of
matches and is as barewords in on* attributes, specifically.
I don't follow.
On Mon, Nov 21, 2011 at 8:54 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
You're not misunderstanding, but you're wrong. ^_^ The element
itself is put in the lookup chain before document. See this testcase:
!DOCTYPE html
button onclick=alert(namespaceURI)foo/button
(namespaceURI was
On 22/11/11 3:23 AM, Boris Zbarsky wrote:
On 11/21/11 10:56 AM, Tab Atkins Jr. wrote:
On Mon, Nov 21, 2011 at 7:22 AM, Boris Zbarskybzbar...@mit.edu wrote:
What's the current state of matchesSelector? Are we confident
enough in the
name and such to unprefix it?
I think that
I think this is the only sane solution to this problem. Lets split up the
Element interface. I'm not attached to these names, but something
like ElementExposed and Element. Element inherits (mixins?) ElementExposed
and only the methods on ElementExposed are exposed to the on* lookup chain.
On 11/21/11 8:31 PM, Aryeh Gregor wrote:
The lookup chain is first document
then window, with no elements anywhere, right?
The lookup order is the element the on* attribute is on, then the
element's form if it's a form control (more or less; details are in the
spec), then the document, then
On 11/21/11 9:58 PM, Ojan Vafai wrote:
I think this is the only sane solution to this problem. Lets split up
the Element interface. I'm not attached to these names, but something
like ElementExposed and Element. Element inherits (mixins?)
ElementExposed and only the methods on ElementExposed are
Yehuda Katz
(ph) 718.877.1325
On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/21/11 11:31 AM, Tab Atkins Jr. wrote:
1) Make sense.
2) Not break existing content.
3) Be short.
.matches
.is
I like .is, the name jQuery uses for this purpose. Any reason
On 30/08/11 4:19 PM, Jonas Sicking wrote:
Indeed! I think it's already been decided that all non-mutating
functions should be added to NodeLists and other list-like DOM
objects. I believe Cameron is still working on the specifics of that.
Shortly before the LC#2 was published, I added an
On Mon, Oct 24, 2011 at 11:17 AM, Cameron McCormack c...@mcc.id.au wrote:
On 30/08/11 4:19 PM, Jonas Sicking wrote:
Indeed! I think it's already been decided that all non-mutating
functions should be added to NodeLists and other list-like DOM
objects. I believe Cameron is still working on the
On 24/10/11 11:51 AM, Jonas Sicking wrote:
I think we have three types of array-like objects:
1. Objects like the one returned from getElementsByTagName where
modifications to the array just doesn't make sense.
2. Objects like the one returned from HTMLInputElements.files where
modifications to
On Mon, Oct 24, 2011 at 11:57 AM, Cameron McCormack c...@mcc.id.au wrote:
On 24/10/11 11:51 AM, Jonas Sicking wrote:
I think we have three types of array-like objects:
1. Objects like the one returned from getElementsByTagName where
modifications to the array just doesn't make sense.
2.
On 24/10/11 12:14 PM, Jonas Sicking wrote:
Based on my testing, many methods wouldn't throw for zero-size
array-like objects. Similarly, methods like .push(), .unshift() and
.slice() wouldn't throw if no entries were actually requested to be
added or removed. And .reverse() wouldn't throw for
On Mon, Oct 24, 2011 at 3:02 PM, Cameron McCormack c...@mcc.id.au wrote:
On 24/10/11 12:14 PM, Jonas Sicking wrote:
Based on my testing, many methods wouldn't throw for zero-size
array-like objects. Similarly, methods like .push(), .unshift() and
.slice() wouldn't throw if no entries were
Hi,
Based on the ongoing discussion, I've put together the following list
of requirements and sumarised use cases that should be met by the design
of new features in selectors API.
*Use Cases*
1. Select elements that are descendants of specific Element node, where
all elements matched
On Mon, Aug 29, 2011 at 9:40 AM, Aryeh Gregor a...@aryeh.name wrote:
On Thu, Aug 25, 2011 at 7:17 PM, Jonas Sicking jo...@sicking.cc wrote:
.push and .pop are generic and work on anything that looks like an
Array. However they don't work on NodeList because NodeList isn't
mutable.
. . .
On Aug 30, 2011, at 10:33 AM, Jonas Sicking wrote:
My point was that it was a mistake for querySelectorAll to return a
NodeList. It should have returned an Array. Sounds like people agree
with that then?
I think it’s better to return an immutable object (mutable objects are source
of
On Tue, Aug 30, 2011 at 2:32 AM, Julien Richard-Foy
jul...@richard-foy.fr wrote:
On Aug 30, 2011, at 10:33 AM, Jonas Sicking wrote:
My point was that it was a mistake for querySelectorAll to return a
NodeList. It should have returned an Array. Sounds like people agree
with that then?
I think
On 30 août 2011, at 18:07, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Aug 30, 2011 at 2:32 AM, Julien Richard-Foy
jul...@richard-foy.fr wrote:
I think it’s better to return an immutable object (mutable objects are
source of programming errors). But this immutable object should have
On Tue, Aug 30, 2011 at 4:33 AM, Jonas Sicking jo...@sicking.cc wrote:
My point was that it was a mistake for querySelectorAll to return a
NodeList. It should have returned an Array. Sounds like people agree
with that then?
I don't have a problem with that, if it can be changed safely.
On Tue, Aug 30, 2011 at 2:25 PM, Aryeh Gregor a...@aryeh.name wrote:
On Tue, Aug 30, 2011 at 4:33 AM, Jonas Sicking jo...@sicking.cc wrote:
My point was that it was a mistake for querySelectorAll to return a
NodeList. It should have returned an Array. Sounds like people agree
with that then?
On Thu, Aug 25, 2011 at 7:17 PM, Jonas Sicking jo...@sicking.cc wrote:
.push and .pop are generic and work on anything that looks like an
Array. However they don't work on NodeList because NodeList isn't
mutable.
. . .
None of these are *mutable* functions.
Oh, right. I misunderstood you.
On 30/08/11 4:40 AM, Aryeh Gregor wrote:
Oh, right. I misunderstood you. Yes, obviously we wouldn't expose
things like .push or .pop on NodeList, since they wouldn't make sense.
But we should expose things like .forEach, etc. Any reason not to?
I should point out that on platform array
That works, but what is the advantage? And .push/.pop or other
mutating functions wouldn't work.
All mutable functions will work (forEach, map, etc.) and bring a better
expressiveness to the code.
Not if he 'this' object is a NodeList.
Yes, sorry I meant all “immutable” functions
On Wed, Aug 24, 2011 at 12:04 PM, Aryeh Gregor a...@aryeh.name wrote:
On Wed, Aug 24, 2011 at 1:27 PM, Jonas Sicking jo...@sicking.cc wrote:
I agree with this, but it might be too late to make this change.
The problem is that if we returned an Array object, it would not have
a .item function,
On 25 août 2011, at 08:33, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Aug 24, 2011 at 12:04 PM, Aryeh Gregor a...@aryeh.name wrote:
On Wed, Aug 24, 2011 at 1:27 PM, Jonas Sicking jo...@sicking.cc wrote:
I agree with this, but it might be too late to make this change.
The problem is that
On Wed, Aug 24, 2011 at 11:47 PM, Julien Richard-Foy
jul...@richard-foy.fr wrote:
On 25 août 2011, at 08:33, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Aug 24, 2011 at 12:04 PM, Aryeh Gregor a...@aryeh.name wrote:
On Wed, Aug 24, 2011 at 1:27 PM, Jonas Sicking jo...@sicking.cc wrote:
I
On Thu, Aug 25, 2011 at 2:33 AM, Jonas Sicking jo...@sicking.cc wrote:
That works, but what is the advantage?
The same advantage as having those methods work for Array. :)
They're useful for lots of stuff.
And .push/.pop or other mutating functions wouldn't work.
Right. I'm only talking
I agree with this, but it might be too late to make this change.
The problem is that if we returned an Array object, it would not have
a .item function, which the currently returned NodeList has.
I guess we could return a Array object and add a .item function to it.
/ Jonas
On Sun, Aug 21,
On Sun, Aug 21, 2011 at 1:52 PM, Julien Richard-Foy
jul...@richard-foy.fr wrote:
Since Javascript 1.6, a lot of useful collection functions are defined for
Array [1]. Unfortunately, they can’t be used directly with results returned by
.querySelectorAll, or even .getElementsByTagName since these
Since Javascript 1.6, a lot of useful collection functions are defined for
Array [1]. Unfortunately, they can’t be used directly with results returned by
.querySelectorAll, or even .getElementsByTagName since these functions return
NodeLists.
I understand the DOM API is defined without a
we handled null
in selectors-api, for which we used to stringify as null.
I've been informed that Cameron has plans to update WebIDL to make
this the default too, but hasn't yet done so.
FYI, I made that change yesterday.
--
Cameron McCormack ≝ http://mcc.id.au/
On 2011-05-09 22:31, Jonas Sicking wrote:
On Mon, May 9, 2011 at 9:22 AM, Lachlan Huntlachlan.h...@lachy.id.au wrote:
Every other tested property on HTML*Element interfaces stringified to
null.
What about namespaceURI, in various APIs (DOM-Core, DOM-XPath).
Node.namespaceURI is readonly
On 2011-05-07 16:03, Lachlan Hunt wrote:
(I don't have results for IE yet because the testharness script I used
to write the tests doesn't work in IE.)
I've now tested IE9, which did give me results. The following
properties are all stringified to .
* BODY .text, .bgColor, .link, .vLink,
On Mon, May 9, 2011 at 9:22 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
On 2011-05-07 16:03, Lachlan Hunt wrote:
(I don't have results for IE yet because the testharness script I used
to write the tests doesn't work in IE.)
I've now tested IE9, which did give me results. The following
On 2011-05-06 15:45, Boris Zbarsky wrote:
On 5/6/11 6:10 AM, Lachlan Hunt wrote:
Recently, in order to resolve a site compatibility issue caused by us
stringifying to null for some properties, we made all DOMString APIs
consistent in their handling of null, such that they now stringify to an
On 5/7/11 10:03 AM, Lachlan Hunt wrote:
For document.write(), Gecko, Webkit (including Safari 5), Opera and IE
write null on both Windows and Mac. I don't know which version of
Safari you were using that gave you a different result.
I was using Safari 5 on Mac; looks like it does something
Hi,
WebIDL currently specifies in the ECMAScript to IDL type mapping [1]
that null stringifies to null by default, unless otherwise specified
with [TreatNullAs=EmptyString].
This definition matches current selectors-api implementations, which do
this conversion for the selectors parameter
On 5/6/11 6:10 AM, Lachlan Hunt wrote:
This definition matches current selectors-api implementations, which do
this conversion for the selectors parameter and this is also the result
expected by the current selectors api test suite. However, according to
information I got from Anne, and from my
,
IE and Opera's implementation of selectors API?
It'll disagree with Webkit, IE, and Opera. It won't quite agree with
Gecko, but it'll be somewhat closer to it. Note that we plan to change
the Gecko implementation, because it's nuts.
AFAICS, all of them expose the querySelector* methods
Hi,
Presently, the IDL in Selectors API defines the NodeSelector
interface using [Supplemental, NoInterfaceObject].
I'm not quite sure why I have supplemental in there, but it seems to be
left over from an old edit that should have been removed, since
NodeSelector is not a pre-existing
On 4/1/11 4:51 PM, Lachlan Hunt wrote:
[Supplemental]
interface Element {
Element querySelector(in DOMString selectors, in optional any
...
}
This adds another method to Element.prototype
[NoInterfaceObject]
interface NodeSelector {
Element querySelector(in DOMString selectors, in optional
Lachlan Hunt:
[Supplemental]
interface Element {
Element querySelector(in DOMString selectors, in optional any
...
}
This adds another method to Element.prototype
[NoInterfaceObject]
interface NodeSelector {
Element querySelector(in DOMString selectors, in optional any
...
};
Hi folks,
I am putting together an implementation report for Selectors API, but I
don't have handy access to a copy of Windows/IE9 - if anyone who does has
the couple of minutes needed to visit
http://dev.w3.org/2006/webapi/selectors-api-testsuite/001.html
http://dev.w3.org/2006/webapi
(Using IE9 RC1)
On 2/22/11 4:17 PM, Charles McCathieNevile wrote:
http://dev.w3.org/2006/webapi/selectors-api-testsuite/001.html
100%
http://dev.w3.org/2006/webapi/selectors-api-testsuite/002.html
100%
http://dev.w3.org/2006/webapi/selectors-api-testsuite/003.html
I get a 404.
Cheers
On Feb/22/2011 4:40 PM, ext Mike Taylor wrote:
http://dev.w3.org/2006/webapi/selectors-api-testsuite/003.html
I get a 404.
The above is missing and x and should be:
http://dev.w3.org/2006/webapi/selectors-api-testsuite/003.xhtml
On Tue, 22 Feb 2011 22:40:34 +0100, Mike Taylor miketa...@gmail.com
wrote:
http://dev.w3.org/2006/webapi/selectors-api-testsuite/003.html
I get a 404.
http://dev.w3.org/2006/webapi/selectors-api-testsuite/003.xhtml
--
Arve Bersvendsen
Opera Software ASA, http://www.opera.com/
Hello,
I'm not very familiar with how everything works here at w3 but I
believe there are bugs in the final example script in both levels of
selectors-api, including the latest drafts of each. The variable
elms is being referenced but is not defined. Instead the variable
list is declared which
in the recent 10.5x
builds.
WebKit (Safari and Chrome) is still failing 16 of the baseline tests.
[1] http://dev.w3.org/2006/webapi/selectors-api-testsuite/
The test suite contains a test that asserts that an exception should be
thrown when no arguments are passed to querySelector
On 5/6/10 10:44 AM, Stewart Brodie wrote:
Taking the null, explicit undefined and implicit undefined test cases
together, I don't think I've got any two browsers here that behave the same
way. :-/
Yes, that's why we can't exit CR. ;)
Note that part of the issue here is that the spec
+public-webapps, -team-webapps
On 2010-05-04 18:23, Arthur Barstow wrote:
The Selectors API Candidate says:
[[
http://www.w3.org/TR/2009/CR-selectors-api-20091222/
There are several known implementations believed to be complete and
interoperable (or on the point of being so) and the WebApps
On Wed, May 5, 2010 at 4:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, May 5, 2010 at 4:56 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
I have not been able to test IE9 because I don't have access to Windows
Vista or 7. I would appreciate it if anyone who has a copy of the last
On Wednesday 20 January 2010, Andrew Fedoniouk wrote:
Daniel Glazman wrote:
I would recommend dropping the pseudo-class :scope and make a
simpler model where a fictional :scope pseudo-class and a
descendant combinator are prepended to all selectors passed as the
argument of the
On 1/21/10 11:11 AM, Bert Bos wrote:
Here are some examples of relations that always hold. (Assume e is an
element != NULL.)
e.querySelector(*) == e.querySelector(:root)
Not unless we've recently redefined :root. Can you point me to the
place where that happened?
On Thu, Jan 21, 2010 at 10:11 AM, Bert Bos b...@w3.org wrote:
2) Drop queryScopedSelector() and queryScopedSelectorAll(). It is
trivially easy to replace a call to queryScopedSelector() by a call to
querySelector(). All you have to do is replace
e.queryScopedSelector(x)
by
On Thursday 21 January 2010, Boris Zbarsky wrote:
On 1/21/10 11:11 AM, Bert Bos wrote:
Here are some examples of relations that always hold. (Assume e is
an element != NULL.)
e.querySelector(*) == e.querySelector(:root)
Not unless we've recently redefined :root. Can you point me
On 1/21/10 1:01 PM, Bert Bos wrote:
e.querySelector(*) == e
Nope. querySelector on an element can only return descendants of the
element. In fact, e.querySelector(*) will return the element's
first element child, if any.
That's surprising... What is the reason to not apply the
Hi, folks-
Since the Selectors API is so closely tied to CSS Selectors, which may
affect implementations and the development of the CSS specs, I would
suggest that there be a closer working relationship between the editors
of Selectors API and the CSS WG. It's a bad sign of coordination
Daniel Glazman wrote:
I would recommend dropping the pseudo-class :scope and make a simpler
model where a fictional :scope pseudo-class and a descendant
combinator are prepended to all selectors passed as the argument of
the corresponding APIs.
There are cases where you will need
Hi there.
(this message contains personal comments and does not represent an
official response from the CSS WG)
I have read the recent Selectors API Level 2 draft [1] and have a few
important comments to make:
1. I don't like the idea of refNodes. I think having the APIs specified
On Sun, Jan 10, 2010 at 11:40 PM, Boris Zbarsky bzbar...@mit.edu wrote:
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
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_ of |element|) is
different from
On 11/01/10 8:55 PM, Lachlan Hunt wrote:
In the following forms :scope is misleading:
element.queryScopedSelector(:scope + *)
element.queryScopedSelector(:scope ~ *)
What's misleading about that? :scope would match the context node
(what the element variable points to), and would return
On 1/11/10 4:55 AM, Lachlan Hunt wrote:
When there's no reference nodes passed and no :scope selector used, the
behaviour of querySelector and querySelectorAll is unchanged from v1. If
there is a :scope selector used, then it matches the context node. If
there are also additional reference nodes
On 11/01/10 6:40 PM, Boris Zbarsky wrote:
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
101 - 200 of 496 matches
Mail list logo
