RE: Call for Consensus - Selectors API to Candidate Rec
I went through the test results in IE8 just to see what the breakdown was and thought I'd pass this info along. I appreciate the thoroughness of these tests, though it bothers me a bit that we get hammered because of the various WebIDL binding issues (e.g., IE8's exception can't be mapped to DOMException.SYNTAX_ERR). Having said that, I understand the desire to be precise and test not only the Selectors API but also the WebIDL binding dependencies that go with it. Current pass rate: 47.4% Best possible current pass rate (excluding WebIDL issues): 1241 tests (57.3%) Best possible pass rate (excluding bugs/WebIDL issues): 1539 tests (71.1%) I'd like to say that 29.9% of the remaining tests are above and beyond the CSS2.1 spec's defined selectors--however, IE8 supports _some_ of the CSS3 selectors already, so it's not such a clean division of the percentages :-) John, thanks again for authoring these tests. To all: I'm still working on collecting IE8 internal test cases and evaluating their suitability for the official test suite. Thanks for your patience--I hope to get back to you in a week or two (been pretty busy here). -Travis Analysis below 1 - Actual Selectors API bugs 288 tests (13.3%) (48 tests) Passing null/undefined/[nothing] to querySelector/querySelectorAll (we don't throw an exception here but should). Note, throwing an exception would move these tests into the WebIDL binding dependencies category based on the test case design. (240 tests) Whitespace trimming: removing superfluous whitespace before/after the selector. The tests include spaces [ ], tabs [\t], newlines [\n], and carriage returns [\r]. 2 - Tests IE8 cannot pass due to dependency on WebIDL bindings 216 tests (9.9%) (8 tests) An Interface check fails (says we don't support querySelector/All) because typeof obj.querySelector is object not function -- this is related to general function bindings for Jscript which are not well supported now. (16 tests) Empty string tests fail (we correctly throw an exception, we just don't support the DOMException WebIDL binding with constant value SYNTAX_ERR). NOTE: We do support the Error interface object, but not the constants... (192 tests) Negative tests (that verify that we fail when we should fail)-- we throw exceptions as expected, but fail the test per the reason listed previously (not supporting the DOMException WebIDL binding with constant value SYNTAX_ERR). 3 - Tests IE8 rightfully fails 657 tests (30.3%) (10 tests) Failures due to Bad existing CSS selector support - Element.querySelectorAll: .attrStart .t3[align^=] (5) - Element.querySelectorAll: .attrEnd .t3[align$=] (5) (647 tests) Failures due to unsupported CSS3 Selectors - :root (18) - :nth-last-child (58) - :nth-child (108) - :nth-of-type (42) - :nth-last-of-type (56) - :not (66 unique, 156 in combination w/other non-supported selectors) - :only-of-type (66) - :last-child (35) - :first-of-type (28) - :last-of-type (28) - :only-child (30) - :empty (41) - :enabled (14) - :disabled (15) - :checked (29) - :target (13) -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of John Resig Sent: Friday, February 13, 2009 6:33 AM To: Lachlan Hunt Cc: Charles McCathieNevile; WebApps WG Subject: Re: Call for Consensus - Selectors API to Candidate Rec Firefox appears to have some issues that might related to the API, though I haven't investigated the cause of those yet, so I don't know for sure. Unfortunately, IE8 can't run John's tests because it relies on some DOM2 features that aren't yet supported, so the testing framework would need to be rewritten to make it work. Just to update: The test suite now runs in IE 8. Demo: http://ejohn.org/apps/selectortest/ As of last night's nightly WebKit has the first 100% passing implementation. --John
Re: [selectors-api] Test Suite Analysis (was: Call for Consensus - Selectors API to Candidate Rec)
Travis Leithead wrote: I went through the test results in IE8 just to see what the breakdown was and thought I'd pass this info along. Thanks for this analysis, it's very informative. 1 - Actual Selectors API bugs 288 tests (13.3%) (48 tests) Passing null/undefined/[nothing] to querySelector/querySelectorAll (we don't throw an exception here but should). Note, throwing an exception would move these tests into the WebIDL binding dependencies category based on the test case design. Note that with the recent change to the handling of null and undefined, IE's behaviour is actually correct because it stringifies them to null and undefined. As for calling them without passing any parameters, I'm not exactly sure whether or not an exception should be thrown. The current behaviour of browsers is: * Opera and Gecko throw exceptions due to the wrong number of arguments * IE behaves as if null was passed, stringifies to null * WebKit behaves as if undefined was passed, stringifies to undefined It appears that the test suite currently expects an exception to be thrown. I'm not sure if that really is the correct behaviour or not. It seems like something WebIDL should define, but I couldn't find anything in the spec on the issue. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Stringifying undefined (was: Call for Consensus - Selectors API to Candidate Rec)
On Fri, 13 Feb 2009 14:23:08 +0100, Lachlan Hunt lachlan.h...@lachy.id.au wrote: If we could do the change quickly and have all browsers commit to making this change relatively quickly, preferably before shipping, and then demonstrate interoperability, then it is theoretically possible. But I don't know. I've CC'd Rune, one of our developers, who can comment on whether or not we could or would make the change. Should be easy to make that change for the selectors api, at least. -- Rune Lillesveen Senior Core Developer Opera Software ASA
Re: [selectors-api] Stringifying undefined (was: Call for Consensus - Selectors API to Candidate Rec)
On Fri, Feb 13, 2009 at 5:23 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
Cameron McCormack wrote:
Boris Zbarsky:
On John Resig's tests in particular, every single failure in Gecko is
due to a violation of this part of the API:
Undefined=Empty
This is using a WebIDL syntax from a working draft that we don't
implement yet, and the current JavaScript DOM binding in Gecko always
converts undefined in parameters to the string undefined.
I started (but did not finish yet) looking at all the uses of DOMString in
various web specs to see what the default behaviour should be for both
[Null] and [Undefined]. So far, it seems that stringifying undefined to
undefined is much more widely implemented:
http://mcc.id.au/2009/01/string-handling/string-handling
If that does end up being the more common behaviour, I'll change the
default in Web IDL to be to stringify to undefined unless overridden, and
I would suggest Selectors API to use that behaviour, too.
The following are reasons we ended up with the spec defining to stringify it
to the empty string instead of undefined.
Initially, the spec didn't define any explicit behaviour, implicitly relying
on whatever the default was. When the first few implementations were
tested, there was a lack of interoperability between them. Each
implementation stringified null and undefined to a different combintation of
null, undefined or empty string. So it was decided that this needed to
be resolved by making the issue more explicit.
At the time, we also had the NSResolver in place, and there were use cases
that required return values of null, undefined and to all be treated as
the empty string, meaning no namespace. This was so that JS authors didn't
have to explicitly define the default namespace.
e.g.
function nsresolver(ns) {
uri = {xht: http://www.w3.org/1999/xhtml;,
svg: http://www.w3.org/2000/svg}
return uri[ns];
}
For resolving the default namespace, this would return undefined. And there
were similar cases where it made sense for null or to be returned
instead.
I'm not sure I agree with this reasoning. This also results in that
the 'foo' and 'cheesedoodles' prefixes are resolved to the default
namespace, is that really desired? I'd rather say that the code should
be written as:
function nsresolver(ns) {
uri = {xht: http://www.w3.org/1999/xhtml;,
svg: http://www.w3.org/2000/svg;
: };
return uri[ns];
}
and make undefined stringify to 'undefined'. The result then is that
unknown prefixes will resolve to 'undefined' which will match nothing,
whereas the empty prefix would be resolved to the null namespace. This
would also map nicely to if you want the default namespace to be
something other than the null namespace, simply do something like
function nsresolver(ns) {
uri = {xht: http://www.w3.org/1999/xhtml;,
svg: http://www.w3.org/2000/svg;
: myNamespace};
return uri[ns];
}
/ Jonas
Re: Call for Consensus - Selectors API to Candidate Rec
Charles McCathieNevile: If anyone objects to this approach (which saves some administrative work and some time), please speak up... Web IDL is still a WD. At some point before Rec, I guess selectors-api would need to block on Web IDL progressing. What point should that be? -- Cameron McCormack ≝ http://mcc.id.au/
Re: Call for Consensus - Selectors API to Candidate Rec
On Feb 17, 2009, at 12:30 , Anne van Kesteren wrote: On Tue, 17 Feb 2009 12:26:16 +0100, Cameron McCormack c...@mcc.id.au wrote: Charles McCathieNevile: If anyone objects to this approach (which saves some administrative work and some time), please speak up... Web IDL is still a WD. At some point before Rec, I guess selectors- api would need to block on Web IDL progressing. What point should that be? PR? There does not actually seem to be a requirement in the W3C Process document that e.g. a Recommendation cannot normatively reference a Working Draft by the way... (Not that it would be a very good situation to be in.) It's not ideal, but you can be clear on the fact that you're referencing a specific (dated) WD of WebIDL (so that the interpretation of the IDL you use is without ambiguity) and should inconsistencies arise in later WebIDL drafts you can issue errata (so long as they actually have no impact on the implementation of your Rec). As far as I can find in the Process, the only document you're not allowed to reference is a Rescinded Recommendation. I think that the referencing work in progress rule is just a general best practice but that you can get away with it if you show that you're smart about it and planning for potential issues. On the other hand, applying pressure to finish WebIDL could be cool :) -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: Call for Consensus - Selectors API to Candidate Rec
On Sat, 07 Feb 2009 12:54:03 +0100, Marcos Caceres marcosscace...@gmail.com wrote: Hi John, On Fri, Feb 6, 2009 at 10:00 PM, John Resig jere...@gmail.com wrote: Opera supports publishing this spec as a CR - and if we can get a test suite and interop report in time, in going for a PR straight away. Is this a different test suite from the one published here: http://ejohn.org/apps/selectortest/ http://github.com/jeresig/selectortest/tree/master Or is it just a matter of 'blessing' it? Without having actually looked at the tests, and if they are appropriate, maybe you could consider donating the tests under a RF license to the W3C... just a thought :) Yep. Assuming that you are OK for them to be republished by the WG as officially blessed bits of your work, the WG also has to formally agree that it has a sufficient set of tests. And then we are almost finished... (Others have also mentioned that they would like to contribute tests, and we would certainly accept those for review if they arrive before we are done). cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [selectors-api] Stringifying undefined (was: Call for Consensus - Selectors API to Candidate Rec)
Cameron McCormack wrote:
Boris Zbarsky:
On John Resig's tests in particular, every single failure in Gecko is
due to a violation of this part of the API:
Undefined=Empty
This is using a WebIDL syntax from a working draft that we don't
implement yet, and the current JavaScript DOM binding in Gecko always
converts undefined in parameters to the string undefined.
I started (but did not finish yet) looking at all the uses of DOMString
in various web specs to see what the default behaviour should be for
both [Null] and [Undefined]. So far, it seems that stringifying
undefined to undefined is much more widely implemented:
http://mcc.id.au/2009/01/string-handling/string-handling
If that does end up being the more common behaviour, I’ll change the
default in Web IDL to be to stringify to undefined unless overridden,
and I would suggest Selectors API to use that behaviour, too.
The following are reasons we ended up with the spec defining to
stringify it to the empty string instead of undefined.
Initially, the spec didn't define any explicit behaviour, implicitly
relying on whatever the default was. When the first few implementations
were tested, there was a lack of interoperability between them. Each
implementation stringified null and undefined to a different
combintation of null, undefined or empty string. So it was decided
that this needed to be resolved by making the issue more explicit.
At the time, we also had the NSResolver in place, and there were use
cases that required return values of null, undefined and to all be
treated as the empty string, meaning no namespace. This was so that JS
authors didn't have to explicitly define the default namespace.
e.g.
function nsresolver(ns) {
uri = {xht: http://www.w3.org/1999/xhtml;,
svg: http://www.w3.org/2000/svg}
return uri[ns];
}
For resolving the default namespace, this would return undefined. And
there were similar cases where it made sense for null or to be
returned instead.
This meant that null and undefined had to be stringified to instead
of null and undefined, respectively.
In order to make the handling of null and undefined consistent
throughout the API, it was also decided that passing null and undefined
as the selector parameter should also stringify to the empty string.
This also has the nice authoring benefit of throwing an exception when
an author accidentally passes a undefined or null variable, which would
most likely be a mistake. Having the exception would help with
debugging the problem, whereas simply treating it as null or
undefined strings would just fail to match any elements (unless there
happened to be null and undefined elements in the document, which is
rare)
But now that the NSResolver has been removed, the consistency reasoning
no longer really applies. The benefit to debugging still sort-of does,
but it is certainly debatable.
There are 2 problems with changing the spec now to use the default
behaviour instead of defining the empty string:
1. We are getting ready to go to PR. It would be rather annoying to
have to hold up this for much longer. Although I generally don't
like letting bureaucratic issues like this get in the way of doing
things, if it can be avoided.
2. We already have 2 implementations, Opera and WebKit, that implement
the behaviour as defined, and Mozilla does it for null. IE8 still
stringifies to null and undefined, respectively.
3. If we do this for undefined, should we also do it for null?
(i.e. undefied - undefined, null - null instead of )
If we could do the change quickly and have all browsers commit to making
this change relatively quickly, preferably before shipping, and then
demonstrate interoperability, then it is theoretically possible. But I
don't know. I've CC'd Rune, one of our developers, who can comment on
whether or not we could or would make the change.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: Call for Consensus - Selectors API to Candidate Rec
Firefox appears to have some issues that might related to the API, though I haven't investigated the cause of those yet, so I don't know for sure. Unfortunately, IE8 can't run John's tests because it relies on some DOM2 features that aren't yet supported, so the testing framework would need to be rewritten to make it work. Just to update: The test suite now runs in IE 8. Demo: http://ejohn.org/apps/selectortest/ As of last night's nightly WebKit has the first 100% passing implementation. --John
Re: Call for Consensus - Selectors API to Candidate Rec
John Resig wrote: As of last night's nightly WebKit has the first 100% passing implementation. Interesting. Did they do this by violating the If the user agent also supports some level of CSS, the implementation SHOULD support the same set of selectors in both these APIs and CSS recommendation? I'm not sure what I think of this, if so, Perhaps the test should be testing that selectors API returns the same results as CSS selector matching instead of testing that particular selectors which might become valid CSS in the future are unsupported. That way, if at some point an extended :not syntax is in fact implemented we won't have browsers implementing it failing this test all of a sudden. -Boris
Re: [selectors-api] Stringifying undefined (was: Call for Consensus - Selectors API to Candidate Rec)
Hey Lachlan, thanks for tracking this down. On Feb 13, 2009, at 14:23 , Lachlan Hunt wrote: But now that the NSResolver has been removed, the consistency reasoning no longer really applies. The benefit to debugging still sort-of does, but it is certainly debatable. Given that adding NSResolver (or something like it) is potential for v2, it might be best to keep the thinking that brought us here from it? There are 2 problems with changing the spec now to use the default behaviour instead of defining the empty string: 1. We are getting ready to go to PR. It would be rather annoying to have to hold up this for much longer. Although I generally don't like letting bureaucratic issues like this get in the way of doing things, if it can be avoided. I reckon that if it had to be done, given the size of the change you could get the major stake-holder to okay the change publicly and still go to PR claiming that LC was done through the commenting and that a zero-length CR is fine. Hey, it can feel wrong yet be sooo right. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: Call for Consensus - Selectors API to Candidate Rec
On Thu, Feb 12, 2009 at 8:14 AM, Boris Zbarsky bzbar...@mit.edu wrote: Lachlan Hunt wrote: Firefox appears to have some issues that might related to the API, though I haven't investigated the cause of those yet, so I don't know for sure. On John Resig's tests in particular, every single failure in Gecko is due to a violation of this part of the API: Undefined=Empty This is using a WebIDL syntax from a working draft that we don't implement yet, and the current JavaScript DOM binding in Gecko always converts undefined in parameters to the string undefined. If this part of WebIDL is stable, we can go ahead and implement it, but I see no obvious evidence of that from the WebIDL working draft. Out of curiosity, are there any other methods in the DOM that treat undefined as the empty string? If not, is there really a reason to make these two functions different? An alternative would be to not mention behavior for undefined at all and let it be whatever the default is for WebIDL once that spec makes up its mind. It seems more important to me to behave consistently with other methods than to have any specific behavior for undefined. / Jonas
Re: Call for Consensus - Selectors API to Candidate Rec
Boris Zbarsky: On John Resig's tests in particular, every single failure in Gecko is due to a violation of this part of the API: Undefined=Empty This is using a WebIDL syntax from a working draft that we don't implement yet, and the current JavaScript DOM binding in Gecko always converts undefined in parameters to the string undefined. If this part of WebIDL is stable, we can go ahead and implement it, but I see no obvious evidence of that from the WebIDL working draft. I started (but did not finish yet) looking at all the uses of DOMString in various web specs to see what the default behaviour should be for both [Null] and [Undefined]. So far, it seems that stringifying undefined to undefined is much more widely implemented: http://mcc.id.au/2009/01/string-handling/string-handling If that does end up being the more common behaviour, I’ll change the default in Web IDL to be to stringify to undefined unless overridden, and I would suggest Selectors API to use that behaviour, too. -- Cameron McCormack ≝ http://mcc.id.au/
Re: Call for Consensus - Selectors API to Candidate Rec
Jonas Sicking: An alternative would be to not mention behavior for undefined at all and let it be whatever the default is for WebIDL once that spec makes up its mind. It seems more important to me to behave consistently with other methods than to have any specific behavior for undefined. That sounds like the better solution to me. Of course, that then makes it incumbent on me to finish those tests reasonably soon to determine what that default behaviour should be… -- Cameron McCormack ≝ http://mcc.id.au/
Re: Call for Consensus - Selectors API to Candidate Rec
Cameron McCormack wrote: If that does end up being the more common behaviour, I’ll change the default in Web IDL to be to stringify to undefined unless overridden, For what it's worth, that's what the current WebIDL draft says in any case. -Boris
Re: Call for Consensus - Selectors API to Candidate Rec
On Thu, Feb 12, 2009 at 4:14 PM, Cameron McCormack c...@mcc.id.au wrote: Boris Zbarsky: On John Resig's tests in particular, every single failure in Gecko is due to a violation of this part of the API: Undefined=Empty This is using a WebIDL syntax from a working draft that we don't implement yet, and the current JavaScript DOM binding in Gecko always converts undefined in parameters to the string undefined. If this part of WebIDL is stable, we can go ahead and implement it, but I see no obvious evidence of that from the WebIDL working draft. I started (but did not finish yet) looking at all the uses of DOMString in various web specs to see what the default behaviour should be for both [Null] and [Undefined]. So far, it seems that stringifying undefined to undefined is much more widely implemented: http://mcc.id.au/2009/01/string-handling/string-handling Still not sure that I understand that chart. As I read it, firefox for the namespaceURI parameter of DOMImplementation.createDocument treats undefined as null (hence the 'N' in the second column). However I would have really expected us to treat undefined as the string 'undefined'. I just did a simple test, but it seems to confirm this: document.implementation.createDocument(undefined, 'tjo', null).documentElement.namespaceURI returns the string 'undefined'. Whereas document.implementation.createDocument(null, 'tjo', null).documentElement.namespaceURI returns the null value (not the string 'null'). / Jonas
Re: Call for Consensus - Selectors API to Candidate Rec
Jonas Sicking: Still not sure that I understand that chart. As I read it, firefox for the namespaceURI parameter of DOMImplementation.createDocument treats undefined as null (hence the 'N' in the second column). However I would have really expected us to treat undefined as the string 'undefined'. I just did a simple test, but it seems to confirm this: document.implementation.createDocument(undefined, 'tjo', null).documentElement.namespaceURI returns the string 'undefined'. Whereas document.implementation.createDocument(null, 'tjo', null).documentElement.namespaceURI returns the null value (not the string 'null'). Grr, bug in the test[1], sorry. I was checking doc.namespaceURI instead of doc.documentElement.namespaceURI. WebKit stringifies to undefined too, while Opera treats it as null. I’ll update the results in that row once I reboot into Windows and check IE. Thanks, Cameron [1] http://mcc.id.au/2009/01/string-handling/tests/006-DOMImplementation-createDocument-1.html -- Cameron McCormack ≝ http://mcc.id.au/
Re: Call for Consensus - Selectors API to Candidate Rec
On Thu, Feb 5, 2009 at 2:21 AM, Charles McCathieNevile cha...@opera.com wrote: [1] http://dev.w3.org/2006/webapi/selectors-api/ I've been meaning to read this for months. sorry for the delay, i expect none of my comments are significant, but i enjoy reading and writing This specification introduces two methods that take a group of selectors it requires a script like the following that iterates that = which ? With these methods, it is easier to match a set of Element nodes based on specific criteria. easier than what? (yes, i know the next sentence would explain, but I don't think English allows for that.) The implementation must first trim any leading or trailing whitespace from the value of the selectors parameter. or = and ? If the user agent also supports some level of CSS, the implementation should support the same set of selectors in both these APIs and CSS. This is poorly written, at first parse I concluded that selectors weren't CSS (there is no CSS level 0), and CSS3 comes in modules. The goal is presumably to indicate that if some other entrypoint to CSS supports something, then this API should support the same thing with the same syntax. But it didn't manage to read that way. The NodeList object returned by the querySelectorAll() method must be static, not live. ([DOM-LEVEL-3-CORE], section 1.1.1) Subsequent changes to the structure of the underlying document must not be reflected in the NodeList object. I believe that the parenthetical should be part of the first sentence instead of after the period. DOM3 Core defines several methods for checking for interface support, or for obtaining implementations of interfaces, using feature strings. ([DOM-LEVEL-3-CORE], section 1.3.6) A DOM application can use these methods, each of which accept feature and version parameters, using the values Selectors-API and 1.0 (respectively). I believe that the parenthetical should be part of the first sentence instead of after the period. note that you do sometimes put the period after, as in: If the group of selectors include namespace prefixes that need to be resolved, the implementation must raise a NAMESPACE_ERR exception ([DOM-LEVEL-3-CORE], section 1.4). var x = document.querySelector(#foo, #bar); x would contain the first element in the document with an ID of either foo or bar (or both). 1. could you change 'contain' - i read contain to mean list, which of course is wrong for querySelector() anne suggests be 2. it might be null - or whatever the return is for the case where there's no match 3. i think the '(or both)' bit doesn't add value, even understanding the case where there's a node matching #foo#bar, if it's the first that matches #foo or #bar, it's still the first that matches #foo or #bar and the fact that it matches #foo#bar is absolutely irrelevant The methods can also be invoked on elements. The methods _defined in this specification_ ... In ECMAScript, the language binding also allows NodeLists to be addressed using the array notation, so that loop could be rewritten like this: using array notation This would cause each selected element to be removed from the DOM, but each element will remain in the NodeList. If the list were a live NodeList, removing an item from the DOM would also remove the element from the list and adjust the indexes of subsequent elements. That would have adverse effects upon the loop because not all selected elements would be processed. I know that explanatory text is valuable, but i don't particularly like this explanatory text in a normative section. Could you make this a non-normative note? excluding all others, requires an additional processing to filter the result. requires additional processing, or an additional step
Re: Call for Consensus - Selectors API to Candidate Rec
timeless wrote: This specification introduces two methods that take a group of selectors it requires a script like the following that iterates that = which ? No, that is correct in this case. With these methods, it is easier to match a set of Element nodes based on specific criteria. easier than what? (yes, i know the next sentence would explain, but I don't think English allows for that.) I rephrased it to the following: With these methods, it is easier to match a set of Element nodes based on specific criteria, than having to subsequently filter the result of calling other methods like getElementsByTagName(). The implementation must first trim any leading or trailing whitespace from the value of the selectors parameter. or = and ? I think or is actually correct in this case, but to remove any confusion, I've changed it to and/or. If the user agent also supports some level of CSS, the implementation should support the same set of selectors in both these APIs and CSS. This is poorly written, at first parse I concluded that selectors weren't CSS (there is no CSS level 0), and CSS3 comes in modules. I do not understand what you mean, nor what is wrong with the sentence. What is it about the sentence that implies there is a CSS level 0? Selectors was part of CSS levels 1 and 2, but as of level 3, it's an independent specification. The goal is presumably to indicate that if some other entrypoint to CSS supports something, then this API should support the same thing with the same syntax. But it didn't manage to read that way. I do not understand this either. The point of the sentence is to say if if the UA supports, or at least partially supports, CSS level 1, 2, 3 or any subsequent level, then it should support the same set of Selectors. The NodeList object returned by the querySelectorAll() method must be static, not live. ([DOM-LEVEL-3-CORE], section 1.1.1) Subsequent changes the structure of the underlying document must not be reflected in the NodeList object. ... DOM3 Core defines several methods for checking for interface support, or for obtaining implementations of interfaces, using feature strings. ([DOM-LEVEL-3-CORE], section 1.3.6) A DOM application can use these methods, each of which accept feature and version parameters, using the values Selectors-API and 1.0 (respectively). I believe that the parenthetical should be part of the first sentence instead of after the period. Fixed both. var x = document.querySelector(#foo, #bar); x would contain the first element in the document with an ID of either foo or bar (or both). 1. could you change 'contain' - i read contain to mean list, which of course is wrong for querySelector() I'm not convinced there is a problem with the word contain in this case. 2. it might be null - or whatever the return is for the case where there's no match 3. i think the '(or both)' bit doesn't add value, even understanding the case where there's a node matching #foo#bar, if it's the first that matches #foo or #bar, it's still the first that matches #foo or #bar and the fact that it matches #foo#bar is absolutely irrelevant I removed (or both) and appended or null if there is no such element. The methods can also be invoked on elements. The methods _defined in this specification_ ... I don't think that extra qualification is necessary in this case. In ECMAScript, the language binding also allows NodeLists to be addressed using the array notation, so that loop could be rewritten like this: using array notation I'm fairly sure using the array notation is grammatically correct in this case. This would cause each selected element to be removed from the DOM, but each element will remain in the NodeList. If the list were a live NodeList, removing an item from the DOM would also remove the element from the list and adjust the indexes of subsequent elements. That would have adverse effects upon the loop because not all selected elements would be processed. I know that explanatory text is valuable, but i don't particularly like this explanatory text in a normative section. Could you make this a non-normative note? The entire example section is already non-normative. excluding all others, requires an additional processing to filter the result. requires additional processing, or an additional step Fixed. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Call for Consensus - Selectors API to Candidate Rec
Hi John, On Fri, Feb 6, 2009 at 10:00 PM, John Resig jere...@gmail.com wrote: Opera supports publishing this spec as a CR - and if we can get a test suite and interop report in time, in going for a PR straight away. Is this a different test suite from the one published here: http://ejohn.org/apps/selectortest/ http://github.com/jeresig/selectortest/tree/master Or is it just a matter of 'blessing' it? Without having actually looked at the tests, and if they are appropriate, maybe you could consider donating the tests under a RF license to the W3C... just a thought :) Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: Call for Consensus - Selectors API to Candidate Rec
Jonas Sicking wrote: So do I, and most likely the rest of mozilla. Seconded. -Boris
Re: Call for Consensus - Selectors API to Candidate Rec
Travis Leithead wrote: Microsoft also supports publishing. We'd also like to help by contributing tests for this spec. Who's the best point-of-contact for reviewing and checking in tests? I am. Just send me the tests, or a link to them, and I can work in integrating them, as well as John Resig's tests [1], into the test suite. I started writing one [2], but it's not yet finished. I will be making time to work on it very soon, as it has now become a priority. [1] http://ejohn.org/apps/selectortest/ [2] http://dev.w3.org/cvsweb/2006/webapi/selectors-api-testsuite/ -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Call for Consensus - Selectors API to Candidate Rec
Opera supports publishing this spec as a CR - and if we can get a test suite and interop report in time, in going for a PR straight away. Is this a different test suite from the one published here: http://ejohn.org/apps/selectortest/ http://github.com/jeresig/selectortest/tree/master Or is it just a matter of 'blessing' it? --John
Re: Call for Consensus - Selectors API to Candidate Rec
On Thu, 05 Feb 2009 01:21:09 +0100, Charles McCathieNevile cha...@opera.com wrote: Hi folks, this is a call for consensus to move the Selectors API [1] to Candidate Recommendation, Opera supports publishing this spec as a CR - and if we can get a test suite and interop report in time, in going for a PR straight away. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Call for Consensus - Selectors API to Candidate Rec
On Thu, 05 Feb 2009 01:21:09 +0100, Charles McCathieNevile cha...@opera.com wrote: Hi folks, this is a call for consensus to move the Selectors API [1] to Candidate Recommendation, following the end of the last call. [1] http://dev.w3.org/2006/webapi/selectors-api/ One minor fix: s/and to be/to be/. Otherwise, looks good. kats
Re: Call for Consensus - Selectors API to Candidate Rec
So do I, and most likely the rest of mozilla. / Jonas On Thu, Feb 5, 2009 at 4:55 AM, Charles McCathieNevile cha...@opera.com wrote: On Thu, 05 Feb 2009 01:21:09 +0100, Charles McCathieNevile cha...@opera.com wrote: Hi folks, this is a call for consensus to move the Selectors API [1] to Candidate Recommendation, Opera supports publishing this spec as a CR - and if we can get a test suite and interop report in time, in going for a PR straight away. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Call for Consensus - Selectors API to Candidate Rec
Charles McCathieNevile: this is a call for consensus to move the Selectors API [1] to Candidate Recommendation, following the end of the last call. +1 -- Cameron McCormack ≝ http://mcc.id.au/
Call for Consensus - Selectors API to Candidate Rec
Hi folks, this is a call for consensus to move the Selectors API [1] to Candidate Recommendation, following the end of the last call. The disposition of comments[2] has no formal objections, and I believe all substantive issues are resolved - the only outstanding one is whether i18n accepts the proposal that notes about normalisation should be in CSS specs rather than this one, and in any case that can be resolved editorially since it has no effect on conformance of implementations. [1] http://dev.w3.org/2006/webapi/selectors-api/ [2] http://dev.w3.org/2006/webapi/selectors-api/disposition-of-comments.html As always, silence will be taken as assent, but positive responses are preferred. In addition, since this specification has a number of implementations we may try to have a zero-length CR period (by approving tests and showing that we have interoperability already) - any comments on that approach are welcome. Please provide assent or dissent and any comments by the end of Thursday 12 February. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
