New CfC Re: [Selectors API] Call for Consensus - approve John Resig's tests
ages ago I cha...@opera.com wrote: Thanks to great work by John Resig, informative analysis by Travis, and implementatio work by many, it seems this is the case. To clarify that, this is a call for consensus on the following question: The test suite by John Resig, 2009-02-19 version[1] is a sufficiently complete test suite for the editor's draft version 1.97[2] of Selectors API [1] http://github.com/jeresig/selectortest/blob/4827dedddaea6fa0b70cfdaadeeafef0d732a753/index.html [2] http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?rev=1.97content-type=text/html;%20charset=iso-8859-1 Note that while silence will be taken as assent, this question will not be held to have carried without significant explicit agreement. Nor will it be held to have carried if there is any dissent. It would appear that there was not consent that the tests there were sufficient. It appears that consensus is that they are all valid, which is good :) However, we now have additional tests proposed by Erik Dahlström[1] and Ian Hickson[2,3]. In addition Lachy identified missing tests that show bugs in existing implementations[4]. So we have a new call for consensus on each of four questions: Should we make Erik's proposed changes[1] to the test suite? Should we add Hixie's first test[2]? Should we add Hixie's second test[3]? Do we need tests as described by Lachy[4] [1] http://www.w3.org/mid/op.uqxrarbjgqi...@gnorps.linkoping.osa [2] http://www.hixie.ch/tests/adhoc/dom/selectors/001.html [3] http://www.hixie.ch/tests/adhoc/dom/selectors/002.html [4] http://www.w3.org/mid/49b91637.3050...@lachy.id.au Please reply before 1 May - silence will be assent, positive early answers are preferred (especially if you think there is something we should be discussing still). 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: New CfC Re: [Selectors API] Call for Consensus - approve John Resig's tests
On Wed, 15 Apr 2009, Charles McCathieNevile wrote: So we have a new call for consensus on each of four questions: Should we make Erik's proposed changes[1] to the test suite? Should we add Hixie's first test[2]? Should we add Hixie's second test[3]? Do we need tests as described by Lachy[4] [1] http://www.w3.org/mid/op.uqxrarbjgqi...@gnorps.linkoping.osa [2] http://www.hixie.ch/tests/adhoc/dom/selectors/001.html [3] http://www.hixie.ch/tests/adhoc/dom/selectors/002.html [4] http://www.w3.org/mid/49b91637.3050...@lachy.id.au Please reply before 1 May - silence will be assent, positive early answers are preferred (especially if you think there is something we should be discussing still). I defer to Lachy's expertise on this question. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [Selectors API] Call for Consensus - approve John Resig's tests
On Wed, 04 Mar 2009 11:00:43 +0100, Charles McCathieNevile cha...@opera.com
wrote:
Hi folks,
as a result of the great work by many, it seems we have all the things in
place to move the Selectors API specification directly to Proposed
Recommendation. In order to do so, we need to demonstrate that we have
implementations which prove the spec can be implemented in an
interoperable way.
Thanks to great work by John Resig, informative analysis by Travis, and
implementatio work by many, it seems this is the case. To clarify that,
this is a call for consensus on the following question:
The test suite by John Resig, 2009-02-19 version[1] is a sufficiently
complete test suite for the editor's draft version 1.97[2] of Selectors
API
[1]
http://github.com/jeresig/selectortest/blob/4827dedddaea6fa0b70cfdaadeeafef0d732a753/index.html
[2]
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?rev=1.97content-type=text/html;%20charset=iso-8859-1
Here's a diff containing changes that makes the proposed testsuite file[1] be
XML well-formed, and which adds some tests for SVG elements, and in particular
for the svg:use element, which has special behaviour wrt CSS selectors[3]:
[[
For user agents that support Styling with CSS, the conceptual deep cloning of
the referenced element into a non-exposed DOM tree also copies any property
values resulting from the CSS cascade [CSS2-CASCADE] on the referenced element
and its contents. CSS2 selectors can be applied to the original (i.e.,
referenced) elements because they are part of the formal document structure.
CSS2 selectors cannot be applied to the (conceptually) cloned DOM tree because
its contents are not part of the formal document structure.
]]
I'd like to see the changes below in the final Selectors API testsuite, and
that the testsuite covers the case where the main document is XHTML.
diff --git a/index.html b/index.html
index 11dee36..849cd36 100644
--- a/index.html
+++ b/index.html
@@ -1,5 +1,4 @@
-!DOCTYPE html
-html lang=en dir=ltr id=html class=unitTest title=:root selector
+html lang=en dir=ltr id=html class=unitTest title=:root selector
xmlns=http://www.w3.org/1999/xhtml;
head
meta http-equiv=Content-Type content=text/html; charset=utf-8 /
titleselectorTest/title
@@ -222,7 +221,7 @@
.foo..quux { background: red; color: yellow; }
.bar. { background: red; color: yellow; }
/style
- script
+ script![CDATA[
window.onload = function(){
document.getElementById(toggle).onclick = function(){
document.documentElement.className = this.checked ?
unitTest nopass : unitTest;
@@ -712,9 +711,13 @@
t( Checked UI Element, #form input:checked,
[radio2,check1] );
t( Element Preceded By, p ~ div,
[foo,fx-queue,fx-tests, moretests] );
t( Not, a.blog:not(.link), [mark] );
+ t( Descendent selector on svg:use, use g, [] );
+ t( Child selector on svg:use, g use, [] );
+ t( Empty svg:use, use:empty, [use1, use2, use3] );
+ t( Element selector on SVG, svg#svg4 circle, [circle4] );
}
};
- /script
+ ]]/script
/head
body id=body class=unitTest title=childhood and element type selectors
h1a href=http://www.w3.org/TR/selectors-api/;Selectors API/a Test
Suite/h1
@@ -744,8 +747,8 @@
div class=test attributeValue
div class=blox6 unitTest align=center title=attribute value
selector/div
-div class=blox6 unitTest foo=eacute; title=attribute value selector
with an entity in the attribute and an escaped value in the selector/div
-div class=blox6 unitTest _foo=eacute; title=attribute value
selector with an entity in the attribute, an escaped value in the selector, and
a leading underscore in the attribute name/div
+div class=blox6 unitTest foo=#201; title=attribute value selector
with an entity in the attribute and an escaped value in the selector/div
+div class=blox6 unitTest _foo=#201; title=attribute value selector
with an entity in the attribute, an escaped value in the selector, and a
leading underscore in the attribute name/div
/div
div class=test attributeSpaceSeparatedValues
@@ -759,21 +762,21 @@
div class=unitTest t1 title=[^=] attribute selector/div
div class=unitTest t2 title=[^=] attribute selector/div
div class=unitTest t3 align=center title=[^=] attribute selector
looking for empty string/div
-div class=unitTest t4 foo=eacute;tagada title=[^=] attribute
selector looking for eacute;/div
+div class=unitTest t4 foo=#201;tagada title=[^=] attribute selector
looking for #201;/div
/div
div class=test attrEnd
div class=unitTest t1 title=[$=] attribute selector/div
div class=unitTest t2 title=[$=] attribute selector/div
div class=unitTest t3 align=center title=[$=] attribute selector
looking for empty string/div
-div class=unitTest t4 foo=tagadaeacute;
Re: [Selectors API] Call for Consensus - approve John Resig's tests
On Thu, 5 Mar 2009, Boris Zbarsky wrote: Ian Hickson wrote: However, I don't think the things tested in 002 are controversal. In particular, all the UAs have converged on the behaviour tested by 002-001 for other objects Ah, that wasn't the case last I checked. And again, there's no specification I can find that requires it. WebIDL defines the class name and ECMAScript requires the [object foo] serialisation, if I'm not mistaken. If I'm wrong and it's not required yet, then I guess I have a bug report for heycam. :-) and I think there's no controversy over [002-002] Probably not, though I suspect that Gecko won't implement this any time soon; certainly not until WebIDL stabilizes more. It requires some pretty nontrivial changes. For the Selectors API as far as I can tell it's trivial to implement, no? Just put the APIs on the other interfaces directly. So since everyone is converging on the behaviour tested here, it should be pretty safe. It depends on whether you want tests for behavior that UAs are converging on or for behavior that the relevant specs actually require. Technically, Selectors API does require these, no? I agree that for 002-001 it's more implicit, but 002-002 and 002-003 are explicit. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [Selectors API] Call for Consensus - approve John Resig's tests
Ian Hickson wrote: For the Selectors API as far as I can tell it's trivial to implement, no? Just put the APIs on the other interfaces directly. That fails for non-JS embeddings of Gecko, for various reasons. So no, pretty nontrivial. -Boris
Re: [Selectors API] Call for Consensus - approve John Resig's tests
Boris Zbarsky: Ah, that wasn't the case last I checked. And again, there's no specification I can find that requires it. Ian Hickson: WebIDL defines the class name and ECMAScript requires the [object foo] serialisation, if I'm not mistaken. If I'm wrong and it's not required yet, then I guess I have a bug report for heycam. :-) You can require a certain [[Class]] value at the moment with Web IDL, if you use the [PrototypeRoot] extended attribute. If the host object implements an interface that has the [PrototypeRoot] extended attribute, then the interface the host object implements that has the largest prototype ancestor set is deemed to be the primary prototype interface of the host object. … If a host object has a primary prototype interface, then the value of the internal [[Class]] property MUST be the identifier of that interface. Otherwise, if the host object has no primary prototype interface, the value of the internal [[Class]] property is implementation specific. — http://www.w3.org/TR/WebIDL/#host-objects However, since there’s no Web IDL definition of NodeList that uses [PrototypeRoot], there is no requirement on the value of [[Class]] of the object returned by querySelectorAll(). (We could define that if a host object implements only a single interface, then [[Class]] must be the identifier of that interface. The requirements on particular values for host object [[Prototype]] is still somewhat speculative, and will probably change a bit more.) -- Cameron McCormack ≝ http://mcc.id.au/
Re: [Selectors API] Call for Consensus - approve John Resig's tests
Cameron McCormack: You can require a certain [[Class]] value at the moment with Web IDL, if you use the [PrototypeRoot] extended attribute. And I forgot to mention that since the Object prototype object is required to be in the prototype chain, that its toString would give the “[class X]” stringification. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [Selectors API] Call for Consensus - approve John Resig's tests
Ian Hickson wrote: However, I don't think the things tested in 002 are controversal. In particular, all the UAs have converged on the behaviour tested by 002-001 for other objects Ah, that wasn't the case last I checked. And again, there's no specification I can find that requires it. 002-002 is explicitly required by the IDL block in Selectors API This is the dependency on WebIDL I was talking about. and I think there's no controversy over that particular requirement Probably not, though I suspect that Gecko won't implement this any time soon; certainly not until WebIDL stabilizes more. It requires some pretty nontrivial changes. and 002-003 is a bog-standard DOM test of one of the requirements in the Selectors API that doesn't really depend on WebIDL at all. Sure; I didn't have any issues with that one. So since everyone is converging on the behaviour tested here, it should be pretty safe. It depends on whether you want tests for behavior that UAs are converging on or for behavior that the relevant specs actually require. For that matter, it's not clear to me that test 001 is. Why not? I think everything in 001 is non-controversal and tests only things that are required by Selectors API, no? I was talking about 002-001. -Boris
[Selectors API] Call for Consensus - approve John Resig's tests
Hi folks, as a result of the great work by many, it seems we have all the things in place to move the Selectors API specification directly to Proposed Recommendation. In order to do so, we need to demonstrate that we have implementations which prove the spec can be implemented in an interoperable way. Thanks to great work by John Resig, informative analysis by Travis, and implementatio work by many, it seems this is the case. To clarify that, this is a call for consensus on the following question: The test suite by John Resig, 2009-02-19 version[1] is a sufficiently complete test suite for the editor's draft version 1.97[2] of Selectors API [1] http://github.com/jeresig/selectortest/blob/4827dedddaea6fa0b70cfdaadeeafef0d732a753/index.html [2] http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?rev=1.97content-type=text/html;%20charset=iso-8859-1 Note that while silence will be taken as assent, this question will not be held to have carried without significant explicit agreement. Nor will it be held to have carried if there is any dissent. Please provide responses in this thread on the public mailing list before the end of Sunday, 15 March. 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] Call for Consensus - approve John Resig's tests
On Wed, 4 Mar 2009, Charles McCathieNevile wrote: [...] To clarify that, this is a call for consensus on the following question: The test suite by John Resig, 2009-02-19 version[1] is a sufficiently complete test suite for the editor's draft version 1.97[2] of Selectors API [1] http://github.com/jeresig/selectortest/blob/4827dedddaea6fa0b70cfdaadeeafef0d732a753/index.html [2] http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?rev=1.97content-type=text/html;%20charset=iso-8859-1 I would be betraying my roots if I didn't at least try to find bugs here. :-) I submit the following as extra tests for the test suite: http://www.hixie.ch/tests/adhoc/dom/selectors/001.html http://www.hixie.ch/tests/adhoc/dom/selectors/002.html Also, I would like to ask that we not consider pre-release browsers as proof of implementability. It is often possible to implement something in the lab, as it were, despite there existing practical problems that would prevent the feature from being implementable in end-user software. (This is the reason behind the is shipping condition that the CSS 2.1 CR exit criteria has.) In practice I don't think this would delay our reaching PR much, since all the implementing browsers are likely to reach that stage relatively soon. So I don't agree that we have yet proved interoperability at a level that I think we should aim for. But I think we're very close! -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [Selectors API] Call for Consensus - approve John Resig's tests
Ian Hickson wrote: http://www.hixie.ch/tests/adhoc/dom/selectors/002.html Given the state of WebIDL, it's not clear to me that the test 002 of this test is necessarily required by the spec as it stands. For that matter, it's not clear to me that test 001 is. Also, I would like to ask that we not consider pre-release browsers as proof of implementability. Seconded. -Boris
Re: [Selectors API] Call for Consensus - approve John Resig's tests
On Wed, 4 Mar 2009, Boris Zbarsky wrote: Ian Hickson wrote: http://www.hixie.ch/tests/adhoc/dom/selectors/002.html Given the state of WebIDL, it's not clear to me that the test 002 of this test is necessarily required by the spec as it stands. Yeah, that's why I separated those tests out. However, I don't think the things tested in 002 are controversal. In particular, all the UAs have converged on the behaviour tested by 002-001 for other objects, 002-002 is explicitly required by the IDL block in Selectors API and I think there's no controversy over that particular requirement, and 002-003 is a bog-standard DOM test of one of the requirements in the Selectors API that doesn't really depend on WebIDL at all. So since everyone is converging on the behaviour tested here, it should be pretty safe. For that matter, it's not clear to me that test 001 is. Why not? I think everything in 001 is non-controversal and tests only things that are required by Selectors API, no? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
