Re: [selectors-api] Summary of Feature Requests for v2

[Jonas Sicking]

On Thu, Sep 24, 2009 at 11:21 AM, Lachlan Hunt  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 my previous mail falls into Option A.  Would it address
>>> this issue adequately?  Specifically, defining document.createSelector()
>>> and
>>> a Selector interface that allows running a query like this:
>>>
>>> var elements = [...] // Some Array (or NodeList) of Elements
>>> var selector = document.createSelector("em, strong");
>>> var list = selector.querySelectorAll(elements);
>>>
>>> This is equivalent to iterating over the elements array, running
>>> elements[i].querySelectorAll("em, strong") on each, and then
>>> merging/sorting
>>> all of the results into a single collection.
>>
>> Not a huge fan of that - it seems really backwards.
>
> Could you elaborate?

I had the same reaction as John, though quite possibly for different reasons.

Currently we have an API like node.querySelector(selector). Your
proposed API is selector.querySelector(node). That seems backwards
compared to existing API.

Quite possibly a namechange would make things better though.

/ Jonas

Re: [selectors-api] Summary of Feature Requests for v2

[Sam Weinig]

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 is mozMatchesSelector.

I bet we'd both love to rename it... ;)


Indeed.  The fact that mozilla was implementing it and picked a vendor  
prefixed name for the time being was part of what encouraged me to  
implement it last night.  So, thanks!


-Sam

Re: [selectors-api] Summary of Feature Requests for v2

[John Resig]

> Not quite.  It depends what's being done and which steps need to be
> performed and how.  AIUI, there are 3 major steps involved here.
>
> 1. Obtain a collection of Elements. This could be in one or more
>   Arrays and/or NodeLists, depending on th.
> 2. Iteratively execute a selector query on all elements in the
>   collection, saving the results from each.
> 3. Merge and sort all elements into a single NodeList, removing
>   duplicates.
>
> In order to understand which of those steps need to be optimised by the
> browser with new APIs, it would help if you could explain some typical
> tasks, or use cases, that would need to perform any or all of those steps.
>
> In particular, what type of task would lead to there being more than one
> Array and/or NodeList to be used as input to step 2?
>

var foo = document.querySelectorAll("div.foo");
// do stuff with the divs...

var bar = document.querySelectorAll("div.bar");
// do stuff with the divs...

var items = document.createNodeList(foo, bar).querySelectorAll("ul.items");
// do stuff with the items...

Alternatively, in jQuery we would be doing something like this:

var foo = $("div.foo");
// do stuff with the divs...

var bar = $("div.bar");
// do stuff with the divs...

var items = foo.add( bar ).find("ul.items");
// do stuff with the items...

The important thing here is that:
1) There is only one sub-query being done.
2) That all the ul.items are being aggregated into a single collection, in
document order.


> What type of task would require executing the same selector query over a
> whole collection of elements?
>

The most important case is where there's additional filtering being done.
For example, in jQuery you can do:

$("div.foo")
   .bind("click", function(){})
   .find("span")
 .addClass("foo");

This reduces the total number of query operations down to two if it was
possible to run it against a complete collection.


> And what task would require the results of those to be merged into a single
> list?


The case where $("div").parents() is done, for example. This is a custom
query where we return a set of ancestor elements for each 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:


  

  

  


$("div").parents() should return:
[ html, body, div#one, div#two ]

naturally if this query is being done on two elements the result set will
need to be merged/sorted/uniqued before it can be returned.


>  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 my previous mail falls into Option A.  Would it
>>> address
>>> this issue adequately?  Specifically, defining document.createSelector()
>>> and
>>> a Selector interface that allows running a query like this:
>>>
>>> var elements = [...] // Some Array (or NodeList) of Elements
>>> var selector = document.createSelector("em, strong");
>>> var list = selector.querySelectorAll(elements);
>>>
>>> This is equivalent to iterating over the elements array, running
>>> elements[i].querySelectorAll("em, strong") on each, and then
>>> merging/sorting
>>> all of the results into a single collection.
>>>
>>
>> Not a huge fan of that - it seems really backwards.
>>
>
> Could you elaborate?
>

Right now we have
(Document|Element|DocumentFragment).querySelectorAll(selector) - this makes
sense - you're going from your base root and finding sub-elements using the
selector.

You're proposing sticking the selector some place else and using the
selector as the root, sort of, then passing the collection of elements as
some sort of filter? It's completely backwards.


>  Another alternative would be to implement the merge/sort/unique
>> method and have it return a NodeList (which would, then, have qSA).
>>
>
> The collection of elements (step 1, above) input into the qSA step (step 2)
> wouldn't need to be a sorted list.  Technically, it doesn't even necessarily
> have to be a merged list if the API allows multiple arrays and/or nodelists
> to be provided.  It will have no effect on the result.  The important point
> seems to be that a collection of elements can be provided somehow and that
> the implementation can execute the query on each distinct element in that
> collection.  How exactly that is done is just an API design issue.


Sure - but we can kill two birds with one API stone. Having a
document.createNodeList gives us merge/sort/unique (yay!) and it makes
NodeList.querySelectorAll and NodeList.matchesSelector doubly-useful (yay! -
since they can now be used for normal NodeLists and for array-like
collections, thanks to createNodeList).

--John

Re: [selectors-api] Summary of Feature Requests for v2

[Boris Zbarsky]

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 it... ;)

-Boris

Re: [selectors-api] Summary of Feature Requests for v2

[Boris Zbarsky]

On 9/24/09 2:17 PM, Garrett Smith wrote:

On Thu, Sep 24, 2009 at 6:06 AM, Boris Zbarsky  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, than an optimized browser running on a mobile device with 128
MB RAM.


Did I imply it's slow?  I just listed approximate hardware so that the 
times can be placed in some sort of context.


that said, note that on a mobile device with 128 MB of RAM the RAM is a 
lot more likely to be a problem than the CPU in some ways.  Running out 
of memory is strictly worse than being a little bit slower.  So a lookup 
table may be more of a loss than a win, depending.


-Boris

Re: [selectors-api] Summary of Feature Requests for v2

[Sam Weinig]

On Sep 23, 2009, at 8:37 PM, Jonas Sicking wrote:


On Wed, Sep 23, 2009 at 8:17 PM, John Resig  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 implementation landed. Already have a  
test

suite in place.


And we have a patch :) So this should be available in Firefox 3.6 I  
hope.


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 
]


-Sam

Re: [selectors-api] Summary of Feature Requests for v2

[Garrett Smith]

On Thu, Sep 24, 2009 at 6:06 AM, Boris Zbarsky  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 my machine (a year-plus old laptop)

That is probably many times faster, and can probably be much more
liberal, than an optimized browser running on a mobile device with 128
MB RAM.

Re: [selectors-api] Summary of Feature Requests for v2

[Lachlan Hunt]

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 elements.

B) A more generic API for being able to easily merge and sort
   NodeLists/Arrays of elements.

Option A saves the step of having to run the queries on each individual
element manually and just returns a merged and sorted collection of unique
elements.  But it's limited to running selector queries, rather than any
other getElementsBy*() method to obtain the results.

Option B is more generic in that it could potentially merge and sort any
set of NodeLists, and those NodeLists could be obtained by any method, but
would still require running the queries on each element individually to
obtain the the lists that then need to be merged.


B is a subset of A. You need B in order to implement A.


Not quite.  It depends what's being done and which steps need to be 
performed and how.  AIUI, there are 3 major steps involved here.


1. Obtain a collection of Elements. This could be in one or more
   Arrays and/or NodeLists, depending on th.
2. Iteratively execute a selector query on all elements in the
   collection, saving the results from each.
3. Merge and sort all elements into a single NodeList, removing
   duplicates.

In order to understand which of those steps need to be optimised by the 
browser with new APIs, it would help if you could explain some typical 
tasks, or use cases, that would need to perform any or all of those steps.


In particular, what type of task would lead to there being more than one 
Array and/or NodeList to be used as input to step 2?


What type of task would require executing the same selector query over a 
whole collection of elements?


And what task would require the results of those to be merged into a 
single list?



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 my previous mail falls into Option A.  Would it address
this issue adequately?  Specifically, defining document.createSelector() and
a Selector interface that allows running a query like this:

var elements = [...] // Some Array (or NodeList) of Elements
var selector = document.createSelector("em, strong");
var list = selector.querySelectorAll(elements);

This is equivalent to iterating over the elements array, running
elements[i].querySelectorAll("em, strong") on each, and then merging/sorting
all of the results into a single collection.


Not a huge fan of that - it seems really backwards.


Could you elaborate?


Another alternative would be to implement the merge/sort/unique
method and have it return a NodeList (which would, then, have qSA).


The collection of elements (step 1, above) input into the qSA step (step 
2) wouldn't need to be a sorted list.  Technically, it doesn't even 
necessarily have to be a merged list if the API allows multiple arrays 
and/or nodelists to be provided.  It will have no effect on the result. 
 The important point seems to be that a collection of elements can be 
provided somehow and that the implementation can execute the query on 
each distinct element in that collection.  How exactly that is done is 
just an API design issue.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [selectors-api] Summary of Feature Requests for v2

[John Resig]

>
>  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) A more generic API for being able to easily merge and sort
>   NodeLists/Arrays of elements.
>
> Option A saves the step of having to run the queries on each individual
> element manually and just returns a merged and sorted collection of unique
> elements.  But it's limited to running selector queries, rather than any
> other getElementsBy*() method to obtain the results.
>
> Option B is more generic in that it could potentially merge and sort any
> set of NodeLists, and those NodeLists could be obtained by any method, but
> would still require running the queries on each element individually to
> obtain the the lists that then need to be merged.
>
> Both options present an issue with sorting, since they could result in
> lists that contain both connected and disconnected elements, and the sort
> order for connected elements in relation to disconnected elements would need
> to be defined.
>
> Option B seems potentially harder to define and possibly implement,
> especially if you want to be able to sort merge NodeList objects with Array
> objects.  Since Arrays aren't limited to just containing DOM Nodes, the
> issue of what to do with other types objects and how to sort them along with
> the Nodes is complicated.


B is a subset of A. You need B in order to implement A. Ideally we could
have both options (A for the obvious cases where you already have a NodeList
and which to do another query against the results, which would be faster
than manually going through the results and doing B).

Whereas B is needed in its own right (as I outlined before).


> 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 my previous mail falls into Option A.  Would it address
> this issue adequately?  Specifically, defining document.createSelector() and
> a Selector interface that allows running a query like this:
>
> var elements = [...] // Some Array (or NodeList) of Elements
> var selector = document.createSelector("em, strong");
> var list = selector.querySelectorAll(elements);
>
> This is equivalent to iterating over the elements array, running
> elements[i].querySelectorAll("em, strong") on each, and then merging/sorting
> all of the results into a single collection.


Not a huge fan of that - it seems really backwards. 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,
strong");

createNodeList would create a NodeList holding the DOM nodes in document
order (with duplicates removed). Since it's a proper NodeList we could then
use qSA to find the elements that we want.

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 would be much faster than using Array.filter or some other
method.)


>  If there was a merge/sort/unique method it would drop the need for having
>> a
>> NodeList/Array.querySelectorAll.
>>
>
> Whether we should go for the extra complexity required for this really
> depends on the use case you're trying to address.  Do you just need to merge
> NodeLists that are all obtained via querySelector methods, or do you need to
> merge any random NodeLists or Arrays that could be obtained via
> querySelector*() or getElementsBy*(), or wherever else.


The latter, absolutely. These results could be coming from anywhere - and
could even be coming from non-query methods (like the aforementioned
.parents() method in jQuery which does its own ancestor traversal).

--John

Re: [selectors-api] Summary of Feature Requests for v2

[Lachlan Hunt]

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
until we can create arbitrary NodeLists.


It would simplify the issues that John described in his last e-mail, but 
the exact use cases aren't entirely clear which is making finding and 
determining the most appropriate solution difficult.  I'm hoping John 
can answer this question.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [selectors-api] Summary of Feature Requests for v2

[Lachlan Hunt]

John Resig wrote:

Filtering NodeLists/StaticNodeLists, Queries on NodeLists/StaticNodeLists:

Neither of these are useful, as is, to libraries.


I believe this would be handled using the Array.filter() method, with a
callback that checks if the selector matches the element, as Jonas pointed
out:

  filteredArray = myArrayOfNodes.filter(function(node) { return

node.matchesSelector("some>selector"); });


(That could also work with the above Selector.matches() proposal)



Array.filter() will meet the need of filtering
NodeLists/StaticNodeLists/Arrays of Elements - sure - but it won't meet the
need of NodeList.querySelectorAll (especially if that works with an
array-like collection of DOM elements).


Right, but I'm dealing with that as an entirely separate issue, which I 
disucssed later on in that email.


Basic filtering of nodelists is bug 5864, which I've resolved WONTFIX 
for now because the functionality doesn't seem too desirable or beneficial.


http://www.w3.org/Bugs/Public/show_bug.cgi?id=5864

The issue you're discussing is bug 7707, which is still open.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=7707


The problem is that when you have multiple collections of DOM elements and
you wish to reduce them to a single collection it ends up being a very
expensive task. The steps are as follows:
   - The collections must be merged together into a single array of DOM
elements.
   - The elements must be sorted to be in document order.
   - Duplicate elements must 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 of unique elements.

B) A more generic API for being able to easily merge and sort
   NodeLists/Arrays of elements.

Option A saves the step of having to run the queries on each individual 
element manually and just returns a merged and sorted collection of 
unique elements.  But it's limited to running selector queries, rather 
than any other getElementsBy*() method to obtain the results.


Option B is more generic in that it could potentially merge and sort any 
set of NodeLists, and those NodeLists could be obtained by any method, 
but would still require running the queries on each element individually 
to obtain the the lists that then need to be merged.


Both options present an issue with sorting, since they could result in 
lists that contain both connected and disconnected elements, and the 
sort order for connected elements in relation to disconnected elements 
would need to be defined.


Option B seems potentially harder to define and possibly implement, 
especially if you want to be able to sort merge NodeList objects with 
Array objects.  Since Arrays aren't limited to just containing DOM 
Nodes, the issue of what to do with other types objects and how to sort 
them along with the Nodes is complicated.



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 my previous mail falls into Option A.  Would it 
address this issue adequately?  Specifically, defining 
document.createSelector() and a Selector interface that allows running a 
query like this:


var elements = [...] // Some Array (or NodeList) of Elements
var selector = document.createSelector("em, strong");
var list = selector.querySelectorAll(elements);

This is equivalent to iterating over the elements array, running 
elements[i].querySelectorAll("em, strong") on each, and then 
merging/sorting all of the results into a single collection.



If there was a merge/sort/unique method it would drop the need for having a
NodeList/Array.querySelectorAll.


Whether we should go for the extra complexity required for this really 
depends on the use case you're trying to address.  Do you just need to 
merge NodeLists that are all obtained via querySelector methods, or do 
you need to merge any random NodeLists or Arrays that could be obtained 
via querySelector*() or getElementsBy*(), or wherever else.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [selectors-api] Summary of Feature Requests for v2

[John Resig]

> Filtering NodeLists/StaticNodeLists, Queries on NodeLists/StaticNodeLists:
>> Neither of these are useful, as is, to libraries. What is actually useful
>> is
>> the ability to run these against an array (or array-like collection) of
>> DOM
>> nodes.
>>
>
> I believe this would be handled using the Array.filter() method, with a
> callback that checks if the selector matches the element, as Jonas pointed
> out:
>
>  filteredArray = myArrayOfNodes.filter(function(node) { return
>> node.matchesSelector("some>selector"); });
>>
>
> (That could also work with the above Selector.matches() proposal)
>

Array.filter() will meet the need of filtering
NodeLists/StaticNodeLists/Arrays of Elements - sure - but it won't meet the
need of NodeList.querySelectorAll (especially if that works with an
array-like collection of DOM elements).

The problem is that when you have multiple collections of DOM elements and
you wish to reduce them to a single collection it ends up being a very
expensive task. The steps are as follows:
  - The collections must be merged together into a single array of DOM
elements.
  - The elements must be sorted to be in document order.
  - Duplicate elements must be removed from the collection.

The relevant pieces of code from the Sizzle selector engine can be found
here:
http://github.com/jeresig/sizzle/blob/master/sizzle.js#L134
http://github.com/jeresig/sizzle/blob/master/sizzle.js#L702

As you can probably tell - those sorting functions are very, very,
time-consuming - but are 100% necessary if we wish to return results in the
correct order.

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!).

For example in jQuery you can do:
$(".foo").parents()
(this returns all ancestors of all elements that have a class of "foo")

Those results must be merged/sorted/uniqued in order to be correctly
returned to the user - and since .parents() (or similar) is not
functionality in CSS 3 we're forced to roll our own.

If there was a merge/sort/unique method it would drop the need for having a
NodeList/Array.querySelectorAll.

--John

Re: [selectors-api] Summary of Feature Requests for v2

[Boris Zbarsky]

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 my machine (a year-plus old 
laptop) parsing the ".foo .bar .baz" selector and destroying the 
selector object before returning in Gecko takes about 80% of the 
"overhead" (that is, not walking the tree and doing selector matching) 
time of a querySelector() call.  Or, in numbers, about 5.5us per call. 
Webkit's time for executing my testcase is comparable, though I can't 
tell how much of their time is selector parsing.


If you're doing less than 1,000 calls that involve selectors api per 
second, the selector-parsing time is probably not that relevant.  But I 
don't know what the use cases are here.


-Boris

Re: [selectors-api] Summary of Feature Requests for v2

[Sean Hogan]

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
achieved with a single querySelectorAll().


It was discussed a couple of days ago in IRC. It's based on the
functionality provided and needed by javascript libraries.


Sorry, I forgot to provide the link.  The relevant discussion is 
spread out quite a bit throughout this log, beginning here.


http://krijnhoetmer.nl/irc-logs/whatwg/20090922#l-

I've highlighted the relevant parts.



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 
until we can create arbitrary NodeLists.

Re: [selectors-api] Summary of Feature Requests for v2

[Sean Hogan]

Garrett Smith wrote:

On Thu, Sep 24, 2009 at 12:02 AM, Mike Wilson  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 chime in on the
details on what is needed for making really efficient
behavioural/delegation implementations, and judge the merits
of various optimizations. There has f ex already been mention
of caching "parsed" selectors.




The benefit to that is that the selector text is parsed once, so
something like:-

document.onmouseover = function(ev) {
  if(ev.target.matchesSelector(".infotip")) { /*...*/ }
};

could probably be made more efficient as:-

var selector = QuerySelector.create(".infotip");
document.onmouseover = function(ev) {
  if(selector.matches(ev.target)) { /*...*/ }
};

  


I would be surprised if an implementation didn't create an internal 
lookup table keyed off the selector text.

Re: [selectors-api] Summary of Feature Requests for v2

[Lachlan Hunt]

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 it tries 
to create it.  Otherwise, it will be valid.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [selectors-api] Summary of Feature Requests for v2

[Lachlan Hunt]

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 querySelectorAll().


It was discussed a couple of days ago in IRC. It's based on the
functionality provided and needed by javascript libraries.


Sorry, I forgot to provide the link.  The relevant discussion is spread 
out quite a bit throughout this log, beginning here.


http://krijnhoetmer.nl/irc-logs/whatwg/20090922#l-

I've highlighted the relevant parts.

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [selectors-api] Summary of Feature Requests for v2

[Garrett Smith]

On Thu, Sep 24, 2009 at 12:02 AM, Mike Wilson  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 chime in on the
> details on what is needed for making really efficient
> behavioural/delegation implementations, and judge the merits
> of various optimizations. There has f ex already been mention
> of caching "parsed" selectors.
>

The benefit to that is that the selector text is parsed once, so
something like:-

document.onmouseover = function(ev) {
  if(ev.target.matchesSelector(".infotip")) { /*...*/ }
};

could probably be made more efficient as:-

var selector = QuerySelector.create(".infotip");
document.onmouseover = function(ev) {
  if(selector.matches(ev.target)) { /*...*/ }
};

The type of context where a QuerySelector object would be useful are
described above. That could be abstracted to a factory pattern that
uses selector to match nodes in a delegated event and lazily construct
a wrapper.

QuerySelector could be extended to have properties:
  readonly attribute boolean valid
  StaticNodeList match(in HTMLElement contextNode)

Garrett

Re: [selectors-api] Summary of Feature Requests for v2

[Lachlan Hunt]

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().


It was discussed a couple of days ago in IRC.  It's based on the 
functionality provided and needed by javascript libraries.


Garrett Smith wrote:

Lachlan Hunt wrote:

div2.matchesSelector(":scope~div", div1);


The matching seems backwards. Should be on the matcher, instead of the
element? I don't see the role of the element being something that does
matching. The matching should be something left to some sort of a
Matcher.

A function to get an actual Selector object would allow the program to
creating a cached matcher.

var selector = QuerySelector.create("div.panel");
var isPanel = selector.matches(event.target);


That's an interesting concept.  We could perhaps define something like this:

Interface DocumentSelector {
  Selector createSelector(DOMString selector, [Element scopeElement, 
[boolean impliedScope]]);

}
Interface Selector {
  boolean matches(Node element);
}

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 selector 
and store it, much like createExpression does in DOM 3 XPath.  If a 
contextElement is provided, then that element is defined as the Scope 
Element that matches the :scope pseudo-class.  If impliedScope is set to 
false, the the browser treats it as an ordinary selector.  If it's set 
to true, then it's treated as an implicitly scoped selector that needs 
to be pre-parsed into a valid selector and imply the presence of :scope 
(like ">em, >strong").


A possible extension to consider would be to also allow scopeElement to 
be specified as an array or NodeList of elements, such that :scope will 
match any of the elements in the elements in the array, instead of 
limiting it to just one.


Scripts can then do this:

var selector = document.createSelector(">em,>strong", elm, true);

Or this:

var selector = document.createSelector("h1+:scope>a", [elm1, elm2, 
elm3], false);


And then pass that selector to querySelector*() like

document.querySelectorAll(selector)

And matchesSelector is handled like this:

document.createSelector("input[type=checkbox]").matches(evt.target);

John Resig wrote:

Filtering NodeLists/StaticNodeLists, Queries on NodeLists/StaticNodeLists:
Neither of these are useful, as is, to libraries. What is actually useful is
the ability to run these against an array (or array-like collection) of DOM
nodes.


I believe this would be handled using the Array.filter() method, with a 
callback that checks if the selector matches the element, as Jonas 
pointed out:



filteredArray = myArrayOfNodes.filter(function(node) { return
node.matchesSelector("some>selector"); });


(That could also work with the above Selector.matches() proposal)


If I can do:
document.querySelectorAll.call([document.getElementById("node1"),
document.getElementById("node2")], "div > span"); then yes, this proposal is
useful. Rarely do libraries store raw NodeLists (they need to be converted
into an array or array-like collection first).


So this means that defining the API directly on NodeLists wouldn't 
handle the use cases dealing with arrays of elements, so the 
NodeList.querySelectorAll() idea is out.


Perhaps on the Selector interface described above, we could also define:

Interface Selector {
  boolean  matches(Node element);
  NodeList querySelector(DOMArray nodes)
  NodeList querySelectorAll(DOMArray nodes)
}

(where nodes either accepts an Array or a NodeList containing a 
collection of Document, Element or DocumentFragment nodes)


Then when these methods are run, they iteratively run querySelector() or 
querySelectorAll() on each of the nodes in the collection, using the 
selector and then return the result as a NodeList containing the union 
of unique elemenets in document order.


e.g.
var selector = document.createSelector("input");
selector.querySelectorAll([elm1, elm2, elm3]);

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

RE: [selectors-api] Summary of Feature Requests for v2

[Mike Wilson]

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
behavioural/delegation implementations, and judge the merits
of various optimizations. There has f ex already been mention
of caching "parsed" selectors.

Best regards
Mike

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 
> check whether the event target element matches a given 
> selector.  So it 
> would be something like:
> 
> if (evt.target.matchesSelector(".foo>input.bar")) {
> ...
> }
> 
> -- 
> Lachlan Hunt - Opera Software
> http://lachy.id.au/
> http://www.opera.com/
> 

Re: [selectors-api] Summary of Feature Requests for v2

[Jonas Sicking]

On Wed, Sep 23, 2009 at 9:57 PM, Maciej Stachowiak  wrote:
>
> On Sep 23, 2009, at 5:26 PM, Jonas Sicking wrote:
>
>> On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt 
>> 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
>>> more compatible with how libraries like JQuery work.  This slightly
>>> different from the :scope pseudo-class proposal, see bug for details.
>>
>> Note that what makes the ">strong, >em" selector (which apparently
>> some libraries support) hard to support spec-wise is that that is not
>> in fact valid CSS syntax. It's certainly possible to define behavior
>> for it, it's pretty clear to me how it's intended to work, but it
>> would mean specifying our own syntax.
>>
>> However if supporting commaseparated queries is critical for libraries
>> then I see no other choise. We'll one way or another have to specify
>> our own syntax, though it can be heavily based on the productions in
>> the Selector spec.
>
> I think we can define an algorithm for turning an implicitly scoped
> pseudo-selector like ">strong, >em" into a proper selector using :scope --
> in this case ":scope>strong, :scope>em". We could either have an API entry
> point that takes a scoped pseudo-selector, defined as transforming to a real
> selector plus establishing a scope node, or just present the algorithm as an
> option for libraries that want to expose pseudo-selector syntax.

Indeed, it's certainly possible. I'd like to find out if we can get
away with not doing that though. I'm curious to get feedback on how
far just having a :scope pseudo-class gets us.

/ Jonas

Re: [selectors-api] Summary of Feature Requests for v2

[Maciej Stachowiak]

On Sep 23, 2009, at 5:26 PM, Jonas Sicking wrote:

On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt > 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

more compatible with how libraries like JQuery work.  This slightly
different from the :scope pseudo-class proposal, see bug for details.


Note that what makes the ">strong, >em" selector (which apparently
some libraries support) hard to support spec-wise is that that is not
in fact valid CSS syntax. It's certainly possible to define behavior
for it, it's pretty clear to me how it's intended to work, but it
would mean specifying our own syntax.

However if supporting commaseparated queries is critical for libraries
then I see no other choise. We'll one way or another have to specify
our own syntax, though it can be heavily based on the productions in
the Selector spec.


I think we can define an algorithm for turning an implicitly scoped  
pseudo-selector like ">strong, >em" into a proper selector  
using :scope -- in this case ":scope>strong, :scope>em". We could  
either have an API entry point that takes a scoped pseudo-selector,  
defined as transforming to a real selector plus establishing a scope  
node, or just present the algorithm as an option for libraries that  
want to expose pseudo-selector syntax.


Regards,
Maciej

Re: [selectors-api] Scoped Queries

[Sean Hogan]

Jonas Sicking wrote:

On Wed, Sep 23, 2009 at 6:00 PM, Sean Hogan  wrote:
  

Jonas Sicking wrote:


On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt 
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
more compatible with how libraries like JQuery work.  This slightly
different from the :scope pseudo-class proposal, see bug for details.



Note that what makes the ">strong, >em" selector (which apparently
some libraries support) hard to support spec-wise is that that is not
in fact valid CSS syntax. It's certainly possible to define behavior
for it, it's pretty clear to me how it's intended to work, but it
would mean specifying our own syntax.

  

It is clear how it is intended to work, but it is less powerful than a
:scope selector.
I suggest it is a low priority feature.



But a :scope selector by itself doesn't help if the passed in selector
to the library contains a comma separated selector like "foo, bar".

  

However if supporting commaseparated queries is critical for libraries
then I see no other choise. We'll one way or another have to specify
our own syntax, though it can be heavily based on the productions in
the Selector spec.

/ Jonas
  

Libraries already parse selector queries anyway. And some of them add
non-standard selectors and presumeably will continue to do so. I don't think
it is an issue.



The input I've gotten from library developers is that they would love
to not have to ship a selector engine. Apparently it would reduce the
size of for example jQuery with about 10k which is pretty significant.

/ Jonas

  
They could. If something like the following is not sufficient it 
probably means they aren't happy with the native selector engine. In 
that case they will be providing their own anyway.


Element.prototype.queryScopedSelectorAll = function(selector) {
   var validSel = ":scope " + selector.replace(",", ", :scope ");
   return this.querySelectorAll(validSel);
}

Re: [selectors-api] Scoped Queries

[Sean Hogan]

John Resig wrote:


Libraries already parse selector queries anyway. And some of them
add non-standard selectors and presumeably will continue to do so.
I don't think it is an issue.


However the parsing only happens after the selector has been passed to 
the native querySelectorAll implementation. We assume the qSA will 
provide the fastest solution. If it throws an exception we then branch 
off into the old, slower, selector engine and forget qSA entirely. 
Since there's no good error-reporting coming from qSA we can't, 
reasonably, determine how or why an error happened (was it a syntax 
error (fooisn't (div:nth-of-type(2) in IE 8)? does it look like a valid selector 
but there's no existing implementation (div:first)?).


If there were two solutions, one that forced you to use :scope in 
front of all queries (or sub-queries) and one that had a separate 
method that handled cases like "> div" properly, I'd take the latter. 
Parsing queries sucks and is slow, it's easier to just pass all of 
that off to the browser.


--John

Yes, it will have to be a new method.
"> div" may be unambiguously ":scope > div", but if you allow it then 
people will expect "div p" to be ":scope div p"which would conflict the 
current definition.

Re: [selectors-api] Summary of Feature Requests for v2

[Jonas Sicking]

On Wed, Sep 23, 2009 at 8:17 PM, John Resig  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 implementation landed. Already have a test
> suite in place.

And we have a patch :) So this should be available in Firefox 3.6 I hope.

> Filtering NodeLists/StaticNodeLists, Queries on NodeLists/StaticNodeLists:
> Neither of these are useful, as is, to libraries. What is actually useful is
> the ability to run these against an array (or array-like collection) of DOM
> nodes.

Very good input!

> If I can do:
> document.querySelectorAll.call([document.getElementById("node1"),
> document.getElementById("node2")], "div > span"); then yes, this proposal is
> useful. Rarely do libraries store raw NodeLists (they need to be converted
> into an array or array-like collection first).

I think filtering can easily be done using the filter function that's
available in Firefox these days. Don't know what the implementation
situation is for other UAs. But something like

filteredArray = myArrayOfNodes.filter(function(node) { return
node.matchesSelector("some>selector"); });

For "querySelectorAll on arrays" to work we'd need some function that
can merge multiple nodelists. Once you have that you can easily use
Array.map to get what you need.

> Scoped Queries: Also critical. As it stands, in jQuery, we just punt
> whenever does a query rooted to a DOM element and fallback to the old
> selector engine.

Does the :scope selector solve things for you? Or does it not because
of selectors like "> foo, > bar", or even "foo, bar"?

/ Jonas

Re: [selectors-api] Scoped Queries

[John Resig]

> Libraries already parse selector queries anyway. And some of them add
> non-standard selectors and presumeably will continue to do so. I don't think
> it is an issue.
>

However the parsing only happens after the selector has been passed to the
native querySelectorAll implementation. We assume the qSA will provide the
fastest solution. If it throws an exception we then branch off into the old,
slower, selector engine and forget qSA entirely. Since there's no good
error-reporting coming from qSA we can't, reasonably, determine how or why
an error happened (was it a syntax error (foo div" properly, I'd take the latter. Parsing queries sucks and
is slow, it's easier to just pass all of that off to the browser.

--John

Re: [selectors-api] Scoped Queries

[Jonas Sicking]

On Wed, Sep 23, 2009 at 6:00 PM, Sean Hogan  wrote:
> Jonas Sicking wrote:
>>
>> On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt 
>> 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
>>> more compatible with how libraries like JQuery work.  This slightly
>>> different from the :scope pseudo-class proposal, see bug for details.
>>>
>>
>> Note that what makes the ">strong, >em" selector (which apparently
>> some libraries support) hard to support spec-wise is that that is not
>> in fact valid CSS syntax. It's certainly possible to define behavior
>> for it, it's pretty clear to me how it's intended to work, but it
>> would mean specifying our own syntax.
>>
>
> It is clear how it is intended to work, but it is less powerful than a
> :scope selector.
> I suggest it is a low priority feature.

But a :scope selector by itself doesn't help if the passed in selector
to the library contains a comma separated selector like "foo, bar".

>> However if supporting commaseparated queries is critical for libraries
>> then I see no other choise. We'll one way or another have to specify
>> our own syntax, though it can be heavily based on the productions in
>> the Selector spec.
>>
>> / Jonas
>
> Libraries already parse selector queries anyway. And some of them add
> non-standard selectors and presumeably will continue to do so. I don't think
> it is an issue.

The input I've gotten from library developers is that they would love
to not have to ship a selector engine. Apparently it would reduce the
size of for example jQuery with about 10k which is pretty significant.

/ Jonas

Re: [selectors-api] Summary of Feature Requests for v2

[John Resig]

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 implementation landed. Already have a test
suite in place.

Filtering NodeLists/StaticNodeLists, Queries on NodeLists/StaticNodeLists:
Neither of these are useful, as is, to libraries. What is actually useful is
the ability to run these against an array (or array-like collection) of DOM
nodes.

If I can do:
document.querySelectorAll.call([document.getElementById("node1"),
document.getElementById("node2")], "div > span"); then yes, this proposal is
useful. Rarely do libraries store raw NodeLists (they need to be converted
into an array or array-like collection first).

Scoped Queries: Also critical. As it stands, in jQuery, we just punt
whenever does a query rooted to a DOM element and fallback to the old
selector engine.

Namespace Prefix Resolution: Indifferent.

--John


On Wed, Sep 23, 2009 at 7:51 AM, 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, and is intended to
> start discussion about which ones are really worth focussing on, and how to
> ensure they address the use cases appropriately.
>
>
> *Matches Selector*
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5865
>
> The suggestion is for being able to check if a given element matches a
> given selector.  There is already similar functionality provided by JQuery
> and Mozilla have begun working on an implementation for it in Firefox.
>
> For the basic case, this is fairly trivial.  The method just needs to take
> a selector and evaluate it against the element, and return true or false.
>
> But considering the proposed :scope pseudo-class that has been previously
> discussed here and in the CSS WG, it might also be nice to check if the
> element matches the selector in relation to a specified reference element.
>
> For example, given 2 elements, div1 and div2, you could check if div2 is a
> sibling of div1 like this:
>
> div2.matchesSelector(":scope~div", div1);
>
> In this case, the div1 would be the reference element that is matched by
> :scope.  But we still need to determine how useful such functionality would
> be, and whether it's worth pursuing it in this next version.
>
>
> *Filtering NodeLists*
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5864
>
> The suggestion is for being able to take a NodeList, and filter the nodes
> to obtain a collection of just those that match a given selector.
>
> For example, being able to get a NodeList somehow, do something with it,
> and then filter it more to work with just a subset:
>
> e.g.
> var list = document.querySelctor("div>p");
> // Do something with list, before obtaining the subset
> subset = list.filterSelector(".foo");
> ...
>
> We need to find and document the possible use cases for this feature.
>
>
> *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
> more compatible with how libraries like JQuery work.  This slightly
> different from the :scope pseudo-class proposal, see bug for details.
>
>
> *Collective Queries on NodeLists*
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7707
>
> The suggestion is to be able to run querySelector() and querySelectorAll()
> on NodeList, and have the result be the union of results in document order
> from running the method on each Element in the NodeList.
>
> e.g.
>
> list.querySelectorAll("p");
>
> Would be somewhat equivalent to running list[i].querySelectorAll("p"); for
>  on each element in the list, and then building an array with the union of
> distinct elements from all the results.  I've been told that similar
> functionality for this already exists in JQuery.
>
> I believe the expectation is that both NodeList.querySelector() and
> .querySelectorAll() would work.  The difference is that querySelector() on a
> NodeList would return a NodeList (unlike on Element which just returns a
> single element) containing the first matches from each node in the list.
> i.e. equivalent to running list[i].querySelector() on each node and then
> combining all results into an array.
>
> It also seems sensible to allow the new scoped methods to be used in an
> analogous way on NodeLists.
>
>
> *Namespace Prefix Resolution*
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6290
>
> The most controversial issue of the lot.  Need to clearly document the use
> cases and evaluate the problems being solved, and determine if it's really
> worth addressing in this version.
>
> --
> Lachlan Hunt - Opera Software
> http://lachy.id.au/
> http://www.opera.com/
>
>

Re: [selectors-api] Summary of Feature Requests for v2

[Garrett Smith]

On Wed, Sep 23, 2009 at 4:51 AM, 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, and is intended to
> start discussion about which ones are really worth focussing on, and how to
> ensure they address the use cases appropriately.
>
>
> *Matches Selector*
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5865

That helps event delegation pattern. That is, adding an event handler
to a container and then inspecting the event's target, to see if what
the user interacted with (and what the program should do about it).
This approach tends to be a much more efficient pattern than
traversing through the entire document to match nodes, and then add
event handler callbacks to them.

The existing draft encourages less efficient programming style of
traversing through the document. Pity.

>
> The suggestion is for being able to check if a given element matches a given
> selector.  There is already similar functionality provided by JQuery and
> Mozilla have begun working on an implementation for it in Firefox.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5865

>
> For the basic case, this is fairly trivial.  The method just needs to take a
> selector and evaluate it against the element, and return true or false.
>
> But considering the proposed :scope pseudo-class that has been previously
> discussed here and in the CSS WG, it might also be nice to check if the
> element matches the selector in relation to a specified reference element.
>
> For example, given 2 elements, div1 and div2, you could check if div2 is a
> sibling of div1 like this:
>
> div2.matchesSelector(":scope~div", div1);
>

The matching seems backwards. Should be on the matcher, instead of the
element? I don't see the role of the element being something that does
matching. The matching should be something left to some sort of a
Matcher.

A function to get an actual Selector object would allow the program to
creating a cached matcher.

var selector = QuerySelector.create("div.panel");
var isPanel = selector.matches(event.target);

Garrett

Re: [selectors-api] Summary of Feature Requests for v2

[Sean Hogan]

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().


- Filtering 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, and is 
intended to start discussion about which ones are really worth 
focussing on, and how to ensure they address the use cases appropriately.



*Matches Selector*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5865

*Filtering NodeLists*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5864

*Scoped Queries*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860

*Collective Queries on NodeLists*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7707

*Namespace Prefix Resolution*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6290

Re: [selectors-api] Scoped Queries

[Sean Hogan]

Jonas Sicking wrote:

On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt  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
more compatible with how libraries like JQuery work.  This slightly
different from the :scope pseudo-class proposal, see bug for details.



Note that what makes the ">strong, >em" selector (which apparently
some libraries support) hard to support spec-wise is that that is not
in fact valid CSS syntax. It's certainly possible to define behavior
for it, it's pretty clear to me how it's intended to work, but it
would mean specifying our own syntax.
  


It is clear how it is intended to work, but it is less powerful than a 
:scope selector.

I suggest it is a low priority feature.


However if supporting commaseparated queries is critical for libraries
then I see no other choise. We'll one way or another have to specify
our own syntax, though it can be heavily based on the productions in
the Selector spec.

/ Jonas


  



Libraries already parse selector queries anyway. And some of them add 
non-standard selectors and presumeably will continue to do so. I don't 
think it is an issue.

Re: [selectors-api] Summary of Feature Requests for v2

[Jonas Sicking]

On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt  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
> more compatible with how libraries like JQuery work.  This slightly
> different from the :scope pseudo-class proposal, see bug for details.

Note that what makes the ">strong, >em" selector (which apparently
some libraries support) hard to support spec-wise is that that is not
in fact valid CSS syntax. It's certainly possible to define behavior
for it, it's pretty clear to me how it's intended to work, but it
would mean specifying our own syntax.

However if supporting commaseparated queries is critical for libraries
then I see no other choise. We'll one way or another have to specify
our own syntax, though it can be heavily based on the productions in
the Selector spec.

/ Jonas

Re: [selectors-api] Summary of Feature Requests for v2

[Lachlan Hunt]

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 target element matches a given selector.  So it 
would be something like:


if (evt.target.matchesSelector(".foo>input.bar")) {
   ...
}

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

RE: [selectors-api] Summary of Feature Requests for v2

[Mike Wilson]

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 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 
> on, and how to ensure they address the use cases appropriately.
> 
> 
> *Matches Selector*
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5865
> 
> The suggestion is for being able to check if a given element 
> matches a 
> given selector.  There is already similar functionality provided by 
> JQuery and Mozilla have begun working on an implementation for it in 
> Firefox.
> 
> For the basic case, this is fairly trivial.  The method just needs to 
> take a selector and evaluate it against the element, and 
> return true or 
> false.
> 
> But considering the proposed :scope pseudo-class that has been 
> previously discussed here and in the CSS WG, it might also be nice to 
> check if the element matches the selector in relation to a specified 
> reference element.
> 
> For example, given 2 elements, div1 and div2, you could check 
> if div2 is 
> a sibling of div1 like this:
> 
> div2.matchesSelector(":scope~div", div1);
> 
> In this case, the div1 would be the reference element that is 
> matched by 
> :scope.  But we still need to determine how useful such functionality 
> would be, and whether it's worth pursuing it in this next version.
> 
> 
> *Filtering NodeLists*
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5864
> 
> The suggestion is for being able to take a NodeList, and filter the 
> nodes to obtain a collection of just those that match a given 
> selector.
> 
> For example, being able to get a NodeList somehow, do 
> something with it, 
> and then filter it more to work with just a subset:
> 
> e.g.
> var list = document.querySelctor("div>p");
> // Do something with list, before obtaining the subset
> subset = list.filterSelector(".foo");
> ...
> 
> We need to find and document the possible use cases for this feature.
> 
> 
> *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 more compatible with how libraries like JQuery work.  
> This slightly 
> different from the :scope pseudo-class proposal, see bug for details.
> 
> 
> *Collective Queries on NodeLists*
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7707
> 
> The suggestion is to be able to run querySelector() and 
> querySelectorAll() on NodeList, and have the result be the union of 
> results in document order from running the method on each 
> Element in the 
> NodeList.
> 
> e.g.
> 
> list.querySelectorAll("p");
> 
> Would be somewhat equivalent to running 
> list[i].querySelectorAll("p"); 
> for  on each element in the list, and then building an array with the 
> union of distinct elements from all the results.  I've been told that 
> similar functionality for this already exists in JQuery.
> 
> I believe the expectation is that both NodeList.querySelector() and 
> .querySelectorAll() would work.  The difference is that 
> querySelector() 
> on a NodeList would return a NodeList (unlike on Element which just 
> returns a single element) containing the first matches from 
> each node in 
> the list. i.e. equivalent to running list[i].querySelector() on each 
> node and then combining all results into an array.
> 
> It also seems sensible to allow the new scoped methods to be 
> used in an 
> analogous way on NodeLists.
> 
> 
> *Namespace Prefix Resolution*
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6290
> 
> The most controversial issue of the lot.  Need to clearly 
> document the 
> use cases and evaluate the problems being solved, and 
> determine if it's 
> really worth addressing in this version.
> 
> -- 
> Lachlan Hunt - Opera Software
> http://lachy.id.au/
> http://www.opera.com/
> 
> 

[selectors-api] Summary of Feature Requests for v2

[Lachlan Hunt]

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 
on, and how to ensure they address the use cases appropriately.



*Matches Selector*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5865

The suggestion is for being able to check if a given element matches a 
given selector.  There is already similar functionality provided by 
JQuery and Mozilla have begun working on an implementation for it in 
Firefox.


For the basic case, this is fairly trivial.  The method just needs to 
take a selector and evaluate it against the element, and return true or 
false.


But considering the proposed :scope pseudo-class that has been 
previously discussed here and in the CSS WG, it might also be nice to 
check if the element matches the selector in relation to a specified 
reference element.


For example, given 2 elements, div1 and div2, you could check if div2 is 
a sibling of div1 like this:


div2.matchesSelector(":scope~div", div1);

In this case, the div1 would be the reference element that is matched by 
:scope.  But we still need to determine how useful such functionality 
would be, and whether it's worth pursuing it in this next version.



*Filtering NodeLists*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5864

The suggestion is for being able to take a NodeList, and filter the 
nodes to obtain a collection of just those that match a given selector.


For example, being able to get a NodeList somehow, do something with it, 
and then filter it more to work with just a subset:


e.g.
var list = document.querySelctor("div>p");
// Do something with list, before obtaining the subset
subset = list.filterSelector(".foo");
...

We need to find and document the possible use cases for this feature.


*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 more compatible with how libraries like JQuery work.  This slightly 
different from the :scope pseudo-class proposal, see bug for details.



*Collective Queries on NodeLists*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7707

The suggestion is to be able to run querySelector() and 
querySelectorAll() on NodeList, and have the result be the union of 
results in document order from running the method on each Element in the 
NodeList.


e.g.

list.querySelectorAll("p");

Would be somewhat equivalent to running list[i].querySelectorAll("p"); 
for  on each element in the list, and then building an array with the 
union of distinct elements from all the results.  I've been told that 
similar functionality for this already exists in JQuery.


I believe the expectation is that both NodeList.querySelector() and 
.querySelectorAll() would work.  The difference is that querySelector() 
on a NodeList would return a NodeList (unlike on Element which just 
returns a single element) containing the first matches from each node in 
the list. i.e. equivalent to running list[i].querySelector() on each 
node and then combining all results into an array.


It also seems sensible to allow the new scoped methods to be used in an 
analogous way on NodeLists.



*Namespace Prefix Resolution*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6290

The most controversial issue of the lot.  Need to clearly document the 
use cases and evaluate the problems being solved, and determine if it's 
really worth addressing in this version.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [selectors-api] Test Suite Progress

[Boris Zbarsky]

Lachlan Hunt wrote:
Both Minefield and Webkit trunk are failing those tests for me.  I have 
all but one commented out just so it would make my debugging easier (see 
lines 287 to 292 in 002.html).


Oh, I'd just missed the one failing test.  Showing only failing tests 
helped!


I just checked in a new copy that outputs the exception message for 
debugging.  So based on that, the problem is that when it tries to check 
the style of the found element, it fails because it's dealing with 
elements in namespaces other than the HTML namespace, so they don't have 
a .style property.


Yep.


 I'm not sure what we can do to workaround that easily.


Hmm.  For the any-namespace test you could use a non-HTML node that 
happens to have .style (like SVG, say).


For the no-namespace test, you'd want the harness to be somewhat 
different here...  Maybe ask John Resig if he has any ideas, since he 
presumably knows this code pretty well?


-Boris

Re: [selectors-api] Test Suite Progress

[Lachlan Hunt]

Boris Zbarsky wrote:

Lachlan Hunt wrote:

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 and are not
functioning properly. If anyone can figure out what I've done wrong,
please let me know.


I'm glad to try to figure that out, if you give me some idea of what
"not functioning properly" means here... As far as I can tell, Gecko and
Webkit are both passing the namespace syntax tests you have here. Is the
problem that they're passing when they shouldn't be? Or something else?


Both Minefield and Webkit trunk are failing those tests for me.  I have 
all but one commented out just so it would make my debugging easier (see 
lines 287 to 292 in 002.html).


But for the one that's still uncommented, it's failing.  In the current 
version, the output is now:


FAIL Element.querySelectorAll: .any-namespace *|div, e.code = TypeError: 
Result of expression 'found[f].style' [null] is not an object.


I just checked in a new copy that outputs the exception message for 
debugging.  So based on that, the problem is that when it tries to check 
the style of the found element, it fails because it's dealing with 
elements in namespaces other than the HTML namespace, so they don't have 
a .style property.  I'm not sure what we can do to workaround that easily.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [selectors-api] Test Suite Progress

[Boris Zbarsky]

Lachlan Hunt wrote:
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 and are not 
functioning properly.  If anyone can figure out what I've done wrong, 
please let me know.


I'm glad to try to figure that out, if you give me some idea of what 
"not functioning properly" means here...  As far as I can tell, Gecko 
and Webkit are both passing the namespace syntax tests you have here. 
Is the problem that they're passing when they shouldn't be?  Or 
something else?


-Boris

[selectors-api] Test Suite Progress

[Lachlan Hunt]

Hi,
  I've made some progress with the test suite.

I have now split the test suite up into 3 files, similar to how I 
prevoiusly described [1]:


1. Baseline Tests: HTML with CSS Level 2.1 Selectors.
2. Additional Tests: HTML with Selectors Level 3.
3. Additional Tests: XHTML+SVG with Selectors Level 3.

http://dev.w3.org/2006/webapi/selectors-api-testsuite/

The baseline tests in the first file are a subset of all the tests in 
the second.  To create it, I basically removed any test using a selector 
introduced in Selectors 3 without modifying other tests.


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 and are not 
functioning properly.  If anyone can figure out what I've done wrong, 
please let me know.  Once these are written, they will also be 
incorporated into the third set.


The third set is an XHTML version of the tests which incorporates the 
tests that Erik had submitted [3].  I haven't verified that all these 
tests are functioning properly, I simply applied the patch from Erik 
without modification.


Finally, I still need to merge in the tests from Hixie [4].

If anyone has the time and motivation and would like to assist with 
incorporating/fixing these tests, please let me know.


[1] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1221.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0713.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0788.html
[4] http://www.hixie.ch/tests/adhoc/dom/selectors/001.html

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [selectors api] test suite red values

[Ian Hickson]

On Mon, 20 Jul 2009, Kartikaya Gupta wrote:
> On Sun, 19 Jul 2009 08:05:32 + (UTC), Ian Hickson  wrote:
> > On Sat, 18 Jul 2009, Kartikaya Gupta wrote:
> > > 
> > > I was wondering if the test suite for selectors-api to could be modified 
> > > to include "#FF" (uppercase) as a valid red value in addition to 
> > > "(255, 0, 0)", "#ff", and "red". This doesn't seem to be specced 
> > > anywhere, and our implementation retuns uppercase for hex colors, so 
> > > some of the tests are failing even though we support the functionality.
> > 
> > In fact according to this, uppercase is the only correct serialisation:
> > 
> >http://dev.w3.org/csswg/cssom/#css-value
> > 
> > (We really should find someone to maintain that draft and publish it.)
> 
> Hmm, I missed that, thanks. I would 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 of the implementations, or the CSSOM spec along with some 
of the implementations, or both.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [selectors api] test suite red values

[Kartikaya Gupta]

On Sun, 19 Jul 2009 08:05:32 + (UTC), Ian Hickson  wrote:
> On Sat, 18 Jul 2009, Kartikaya Gupta wrote:
> > 
> > I was wondering if the test suite for selectors-api to could be modified 
> > to include "#FF" (uppercase) as a valid red value in addition to 
> > "(255, 0, 0)", "#ff", and "red". This doesn't seem to be specced 
> > anywhere, and our implementation retuns uppercase for hex colors, so 
> > some of the tests are failing even though we support the functionality.
> 
> In fact according to this, uppercase is the only correct serialisation:
> 
>http://dev.w3.org/csswg/cssom/#css-value
> 
> (We really should find someone to maintain that draft and publish it.)
> 

Hmm, I missed that, thanks. I would 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.

kats

Re: [selectors api] test suite red values

[Ian Hickson]

On Sat, 18 Jul 2009, Kartikaya Gupta wrote:
> 
> I was wondering if the test suite for selectors-api to could be modified 
> to include "#FF" (uppercase) as a valid red value in addition to 
> "(255, 0, 0)", "#ff", and "red". This doesn't seem to be specced 
> anywhere, and our implementation retuns uppercase for hex colors, so 
> some of the tests are failing even though we support the functionality.

In fact according to this, uppercase is the only correct serialisation:

   http://dev.w3.org/csswg/cssom/#css-value

(We really should find someone to maintain that draft and publish it.)

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[selectors api] test suite red values

[Kartikaya Gupta]

Hi,

I was wondering if the test suite for selectors-api to could be modified to 
include "#FF" (uppercase) as a valid red value in addition to "(255, 0, 
0)", "#ff", and "red". This doesn't seem to be specced anywhere, and our 
implementation retuns uppercase for hex colors, so some of the tests are 
failing even though we support the functionality.

Cheers,
kats

Re: Exit criteria Re: [selectors-api] Transitioning to CR

[Lachlan Hunt]

Charles McCathieNevile wrote:

Actually, based on feedback on the list (thanks Maciej and Robin), and
talking to Lachy, we are thinking that we should seperate out the tests
that *require* CSS 3 selectors, to make the test suite check
implementation of the API, and then require at least two 100% complete
and completely interoperable implementations.

I believe Lachy will be following up on this about now - both for the
list and the test suite.


Here is the revised proposal for the exit criteria.

* Tested implementations 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 additional tests, dependent on the following conditions:


* The baseline testsuite comprises tests that check for conformance to
  all requirements in the API using only HTML and Selectors defined in
  CSS 2.1.

* Tests using Selectors introduced in Selectors Level 3, or XHTML+SVG,
  are considered to be additional tests.

* An additional test may be marked as N/A for an implementation if:
  - The test uses a selector that the implementation does not support
  - The test uses XHTML+SVG that the implementation does not support

* Implementations are not required to pass all additional tests,
  however no failures must be caused by an incorrect implementation of
  the API itself. Failures of additional tests caused only by an
  incorrect implementation of Selectors do not count.


This implies that the testsuite should be split into several files:

1. Baseline containing tests using only HTML and CSS 2.1
2. Additional tests using XHTML+SVG and CSS2.1 (equivalent to the
   previous test, but with the addition of SVG-related tests)
3. Additional tests using HTML and Selectors 3
4. Additional tests using XHTML and Selectors 3



--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Exit criteria Re: [selectors-api] Transitioning to CR

[Charles McCathieNevile]

On Wed, 24 Jun 2009 14:58:17 +0200, Arthur Barstow   
wrote:



Lachlan,

On Jun 17, 2009, at 8:15 AM, ext Lachlan Hunt wrote:


Hi,
   In order to complete the transition of Selectors API to CR, there
were a number of things that needed to be done, following the call for
consensus we had in April/May.

http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0471.html

1. Write CR Exit Criteria


I think your proposal is OK.


Actually, based on feedback on the list (thanks Maciej and Robin), and  
talking to Lachy, we are thinking that we should seperate out the tests  
that *require* CSS 3 selectors, to make the test suite check  
implementation of the API, and then require at least two 100% complete and  
completely interoperable implementations.


I believe Lachy will be following up on this about now - both for the list  
and the test suite.


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] Transitioning to CR

[Arthur Barstow]

Lachlan,

On Jun 17, 2009, at 8:15 AM, ext Lachlan Hunt wrote:


Hi,
   In order to complete the transition of Selectors API to CR, there
were a number of things that needed to be done, following the call for
consensus we had in April/May.

http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 
0471.html


1. Write CR Exit Criteria


I think your proposal is OK.


2. Write updated Status of the Document section


Other than a date or two that will need to be updated before  
publication, I think your proposal is OK.



3. Complete the test suite


...


*Test Suite*

Finally, there were a number of additional tests that needed to be
reviewed and either incorporated into the test suite, or rejected.

1. Erik proposed additional tests related to using Selectors API with
SVG content.  His proposal would add SVG directly into the existing  
test
suite file.  However, as the existing file is HTML, not XHTML, this  
will
not work in current browsers, and would instead require the tests  
to be

in a separate XHTML file.

http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/ 
0788.html


I would be interested in getting feedback from implementors about  
whether or not these additional tests should be mandatory.




2. Hixie proposed two sets of tests.  The first seems to be
non-controversial and I believe it should be integrated into the  
test suite.


http://www.hixie.ch/tests/adhoc/dom/selectors/001.html


OK.



Based on past discussion, however, the second set is somewhat
controversial, and I'm not really sure whether or not they should be
included.

http://www.hixie.ch/tests/adhoc/dom/selectors/002.html
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/ 
0637.html


In the absence of strong support for adding this second set, perhaps  
they should not be included.



3. The missing tests that I pointed out relating to the namespace  
syntax

do need to be included, as they will test specific conformance
requirements in Selectors API that are currently not tested in the  
test

suite.

http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/ 
0713.html


Additionally, in order to make the tests easier to count, I think we
should consider grouping the tests according to the level of Selectors
used for a given test, so that tests using CSS2 Selectors can be  
easily

distinguished from those using Selectors Level 3.  In particular, this
would make assessing IE's conformance easier since they don't claim to
support many level 3 selectors and those tests shouldn't be counted.

http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/ 
0585.html
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/ 
0586.html


I will work in John Resig to get those tests integrated into the test
suite soon.


Good. Please let us know when this is completed.

-Regards, Art Barstow

Re: [selectors-api] Names of querySelector() and querySelectorAll() methods

[Dodger]

I realise it's too late, but I thought I'd add my +1 anyway.

I like Gavin's suggestion of selectElement() / selectElements()

getElement() / getElements() could also have been used for consistency
with the existing element selection function names.

. oh well. :-)

P.S. Could someone point me to the "long debates about naming" that João
referred to? I tried searching without success. Thanks.

Re: [selectors-api] Return value of lookupNamespaceURI

[Cameron McCormack]

Boris Zbarsky:
> > If the return value of lookupNamespaceURI is |undefined|, should that  
> > stringify to "" or "undefined"?  Same question for |null|.
> >
> > Note that I'm not sure there's an obvious way to annotate this in web  
> > idl yet.

Cameron McCormack:
> Yeah, there’s no way to specify this at the moment.  We could have the
> same [Null] and [Undefined] extended attributes on the operation, and
> then change the steps in “Native objects implementing interfaces” to
> take these into account.

I’ve added wording to this effect, so that functions on native objects that
implement interfaces have their return values handled in the same way as
when passing JS values to DOMString operation arguments or attributes.

  http://dev.w3.org/2006/webapi/WebIDL/#Null
  http://dev.w3.org/2006/webapi/WebIDL/#Undefined
  http://dev.w3.org/2006/webapi/WebIDL/#es-DOMString

-- 
Cameron McCormack ≝ http://mcc.id.au/

Re: [selectors-api] Transitioning to CR

[Maciej Stachowiak]

On Jun 20, 2009, at 1:39 AM, Charles McCathieNevile wrote:



That's true. THe question is whether a REC makes it easier to get a  
new interoperable implementation. And it's open, as far as I can see.


Assuming we have implementation of everything, twice, and that for  
everything we have at least two implementations that interoperate,  
and that we have a very high level (95% or more) of interoperability  
of at least 3 implementations, and that we have one complete  
implementation, and that we are confident that the barriers to  
completion are now just bugs *that will be fixed* (as opposed to  
bugs that will live forever), the question becomes relevant.


In the meantime, we still don't have any consensus that our test  
suite is ok, so the rest of the question is a bit academic...


... but assuming we get that, and because it seems that we are at  
least very near the above set of assumptions, let's decide whether  
to go the fast or hard way to REC, too. Which means more feedback on  
this question is welcome.


I'd suggest the CR exist criteria should be two implementations that  
100% pass the test suite, i.e. they are individually interoperable on  
every feature, plus agreement from the WG that the test suite is  
correct and thorough. From observed behavior, almost no implementors  
consider the CR level of maturity to be a barrier to adoption, so  
let's do our best to flush out all potential flaws in the spec before  
we go to the essentially frozen state of REC.


Regards,
Maciej

Re: [selectors-api] Transitioning to CR

[Charles McCathieNevile]

On Fri, 19 Jun 2009 19:12:35 +0200, Ian Hickson  wrote:


On Fri, 19 Jun 2009, Robin Berjon wrote:

On Jun 19, 2009, at 17:14 , Lachlan Hunt wrote:
> Robin Berjon wrote:
> > Out of curiosity, why not make it two interoperable implementations  
of
> > *all* the tests, except those stemming from a lack of support for  
CSS?

>
> I was advised to set the requirements low so that it would be easier
> to proceed past CR.  With these requirements, we can get past CR
> relatively quickly.  If we need to wait for at least 2 implementations
> that both get 100%, that will just delay the spec by 6 to 12 months
> awaiting the browser vendors' next release cycle.

I don't have a strong opinion either way, but I am unaware of any
external time pressure on this specification. If there aren't any, why
not delay it so we can do the hard (and right) thing of only shipping
when we have fully demonstrated interoperability?


That seems wiser to me too. The rush is to get interoperable
implementations, not to get RECs.


That's true. THe question is whether a REC makes it easier to get a new  
interoperable implementation. And it's open, as far as I can see.


Assuming we have implementation of everything, twice, and that for  
everything we have at least two implementations that interoperate, and  
that we have a very high level (95% or more) of interoperability of at  
least 3 implementations, and that we have one complete implementation, and  
that we are confident that the barriers to completion are now just bugs  
*that will be fixed* (as opposed to bugs that will live forever), the  
question becomes relevant.


In the meantime, we still don't have any consensus that our test suite is  
ok, so the rest of the question is a bit academic...


... but assuming we get that, and because it seems that we are at least  
very near the above set of assumptions, let's decide whether to go the  
fast or hard way to REC, too. Which means more feedback on this question  
is welcome.


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] Transitioning to CR

[Ian Hickson]

On Fri, 19 Jun 2009, Robin Berjon wrote:
> On Jun 19, 2009, at 17:14 , Lachlan Hunt wrote:
> > Robin Berjon wrote:
> > > Out of curiosity, why not make it two interoperable implementations of
> > > *all* the tests, except those stemming from a lack of support for CSS?
> > 
> > I was advised to set the requirements low so that it would be easier 
> > to proceed past CR.  With these requirements, we can get past CR 
> > relatively quickly.  If we need to wait for at least 2 implementations 
> > that both get 100%, that will just delay the spec by 6 to 12 months 
> > awaiting the browser vendors' next release cycle.
> 
> I don't have a strong opinion either way, but I am unaware of any 
> external time pressure on this specification. If there aren't any, why 
> not delay it so we can do the hard (and right) thing of only shipping 
> when we have fully demonstrated interoperability?

That seems wiser to me too. The rush is to get interoperable 
implementations, not to get RECs.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [selectors-api] Transitioning to CR

[Boris Zbarsky]

Robin Berjon wrote:
Yeah, I have this Ecmascript implementation that only supports variable 
declarations (with a few bugs). But I swear it supports the Selectors API!


Yes, that's why there was an "if" in what I said.  If only English had 
clearer grammatical markers for the subjunctive!


Seriously though, as I explained during the last meeting it's up to the 
WG to reach consensus on the exit criteria, and then up to the WG to 
reach consensus on whether they've been reached or not.


Makes sense to me.  I thought that was the point of Lachlan's mail: to 
see consensus on the former.  Did I misunderstand?


Just to be clear, here are the things that stand between where we are 
and having two 100% interoperable implementations last I looked at the 
tests.


1)  Gecko's handling of null passed to a string value doesn't match
WebIDL (treated as empty string instead of "null");
2)  Webkit's handling no value when a string is expected doesn't match
WebIDL (not sure of the details here).

If we exclude issues regarding which precise selectors should match 
where (as in, bugs in the CSS implementation), then instead of fixing 
both of those, we could fix one of those, and fix Opera's handling of 
null and undefined passed to a string value (doesn't match WebIDL) and 
then we'd also have "interoperable" implementations.


Whether the two issues above should block passing out of CR is up to the 
working group, of course.


-Boris

Re: [selectors-api] Transitioning to CR

[Robin Berjon]

On Jun 19, 2009, at 17:14 , Lachlan Hunt wrote:

Robin Berjon wrote:
Out of curiosity, why not make it two interoperable implementations  
of
*all* the tests, except those stemming from a lack of support for  
CSS?


I was advised to set the requirements low so that it would be easier  
to proceed past CR.  With these requirements, we can get past CR  
relatively quickly.  If we need to wait for at least 2  
implementations that both get 100%, that will just delay the spec by  
6 to 12 months awaiting the browser vendors' next release cycle.


I don't have a strong opinion either way, but I am unaware of any  
external time pressure on this specification. If there aren't any, why  
not delay it so we can do the hard (and right) thing of only shipping  
when we have fully demonstrated interoperability?


--
Robin Berjon - http://berjon.com/
Feel like hiring me? Go to http://robineko.com/

Re: [selectors-api] Transitioning to CR

[Lachlan Hunt]

Robin Berjon wrote:

Out of curiosity, why not make it two interoperable implementations of
*all* the tests, except those stemming from a lack of support for CSS?


I was advised to set the requirements low so that it would be easier to 
proceed past CR.  With these requirements, we can get past CR relatively 
quickly.  If we need to wait for at least 2 implementations that both 
get 100%, that will just delay the spec by 6 to 12 months awaiting the 
browser vendors' next release cycle.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [selectors-api] Transitioning to CR

[Robin Berjon]

On Jun 19, 2009, at 16:57 , Boris Zbarsky wrote:

Robin Berjon wrote:
* Test failures in a given implementation caused by the lack of  
support

for a particular feature of an independent specification are not
counted.


I should note that if we consider WebIDL an "independent  
specification" then we're already there.


Yeah, I have this Ecmascript implementation that only supports  
variable declarations (with a few bugs). But I swear it supports the  
Selectors API!


Seriously though, as I explained during the last meeting it's up to  
the WG to reach consensus on the exit criteria, and then up to the WG  
to reach consensus on whether they've been reached or not. The point  
of specifying them in advance is that it informs the community at  
large about our intentions in terms of how strict we plan to be. Which  
is to say: it's not a conformance clause. We don't need to be anal  
about how it is formulated because we won't be writing tests in the  
future to see if the WG conforms to itself. It's important to say that  
we're testing the API and not actual CSS support, but we needn't go  
overboard in delimiting the criteria.


--
Robin Berjon - http://berjon.com/
Feel like hiring me? Go to http://robineko.com/

Re: [selectors-api] Transitioning to CR

[Boris Zbarsky]

Robin Berjon wrote:

* Test failures in a given implementation caused by the lack of support
 for a particular feature of an independent specification are not
 counted.


...

Out of curiosity, why not make it two interoperable implementations of 
*all* the tests, except those stemming from a lack of support for CSS?


I should note that if we consider WebIDL an "independent specification" 
then we're already there.


-Boris

Re: [selectors-api] Transitioning to CR

[Robin Berjon]

Hi Lachlan,

On Jun 17, 2009, at 14:15 , Lachlan Hunt wrote:

*CR Exit Criteria*

I propose the following as the CR exit criteria:

At least two interoperable implementations of each feature,  
dependent upon the following conditions:


* Each individual test in the test suite must pass in at least two of
 the reviewed implementations.

* Test failures in a given implementation caused by the lack of  
support

 for a particular feature of an independent specification are not
 counted.  This does not apply to failures caused by an incorrect
 implementation of such features. (e.g. IE lacks support for many of
 the CSS3 selectors tested in the test suite, but to be fair, these
 failure should be ignored.)

* Each implementation reviewed must have at least a 95% pass rate, not
 counting ignored tests.


Out of curiosity, why not make it two interoperable implementations of  
*all* the tests, except those stemming from a lack of support for CSS?


--
Robin Berjon - http://berjon.com/
Feel like hiring me? Go to http://robineko.com/

[selectors-api] Transitioning to CR

[Lachlan Hunt]

Hi,
  In order to complete the transition of Selectors API to CR, there 
were a number of things that needed to be done, following the call for 
consensus we had in April/May.


http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0471.html

1. Write CR Exit Criteria
2. Write updated Status of the Document section
3. Complete the test suite

*CR Exit Criteria*

I propose the following as the CR exit criteria:

At least two interoperable implementations of each feature, dependent 
upon the following conditions:


* Each individual test in the test suite must pass in at least two of
  the reviewed implementations.

* Test failures in a given implementation caused by the lack of support
  for a particular feature of an independent specification are not
  counted.  This does not apply to failures caused by an incorrect
  implementation of such features. (e.g. IE lacks support for many of
  the CSS3 selectors tested in the test suite, but to be fair, these
  failure should be ignored.)

* Each implementation reviewed must have at least a 95% pass rate, not
  counting ignored tests.

(With these criteria, I believe the current available implementations in 
at least Firefox, Opera and Safari, will be sufficient to exit CR, even 
though each fails a small subset of the tests.)



*Status of the Document*

In December, I wrote a draft transition request which can be used. 
However, I've made minor updates to the proposed Status of the Document 
section.


---

This section describes the status of this document at the time of its 
publication. Other documents may supersede this document. A list of 
current W3C publications and the latest revision of this technical 
report can be found in the W3C technical reports index at 
http://www.w3.org/TR/.


This is the XXX June 2009 Candidate Recommendation of Selectors API. W3C 
publishes a Candidate Recommendation to indicate that the document is 
believed to be stable and to encourage implementation by the developer 
community. The Web Applications (WebApps) Working Group expects to 
request that the Director advance this document to Proposed 
Recommendation once the Working Group has developed a comprehensive 
Selectors API test suite, and demonstrated at least two interoperable 
implementations for each test. There are several known implementations 
believed to be complete and interoperable (or on the point of being so) 
and the WebApps Working Group expects to develop a test suite and use it 
to show that that these implementations pass by July 2009. The Working 
Group does not plan to request to advance to Proposed Recommendation 
prior to 01 July 2009.


The Last Call Working Draft for this specification resulted in a number 
of Last Call comments which have all been addressed by the Working 
Group, a list of which can be found in the Disposition of Comments.


The W3C Membership and other interested parties are invited to review 
the document and send comments to public-webapps@w3.org (public archive) 
with [selectors-api] in the subject, through 12 December 2008. (Please 
note that a different list was used until mid 2008, so some old messages 
are archived there instead). The editor’s copy of this specification is 
available in W3C CVS. A detailed list of changes is also available from 
the CVS server.


This document was developed by the Web Applications Working Group. The 
Working Group expects to advance this Working Draft to Recommendation 
Status.


Publication as a Candidate Recommendation does not imply endorsement by 
the W3C Membership. This is a draft document and may be updated, 
replaced or obsoleted by other documents at any time. It is 
inappropriate to cite this document as other than work in progress.


This document was produced by a group operating under the 5 February 
2004 W3C Patent Policy. W3C maintains a public list of any patent 
disclosures made in connection with the deliverables of the group; that 
page also includes instructions for disclosing a patent. An individual 
who has actual knowledge of a patent which the individual believes 
contains Essential Claim(s) must disclose the information in accordance 
with section 6 of the W3C Patent Policy.


---


*Test Suite*

Finally, there were a number of additional tests that needed to be 
reviewed and either incorporated into the test suite, or rejected.


1. Erik proposed additional tests related to using Selectors API with 
SVG content.  His proposal would add SVG directly into the existing test 
suite file.  However, as the existing file is HTML, not XHTML, this will 
not work in current browsers, and would instead require the tests to be 
in a separate XHTML file.


http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0788.html

2. Hixie proposed two sets of tests.  The first seems to be 
non-controversial and I believe it should be integrated into the test suite.


http://www.hixie.ch/tests/adhoc/dom/selectors/001.html

Based on past discussion, however, the s

Re: New CfC Re: [Selectors API] Call for Consensus - approve John Resig's tests

[Arthur Barstow]

Hi Lachy - this CfC has ended and my records show there were no  
objections. Given this, we now have a Go to prepare a Candidate  
Recommendation for publication.


I presume the actions, that follow from the set of questions listed  
below, can be addressed during the Candidate period. Do you agree?


Regarding the Candidate's Status of the Document (SotD) that needs to  
define the spec's exit criteria, I think the text Cam used for the  
Element Traversal CR is a reasonable pattern to follow:


 http://www.w3.org/TR/2008/CR-ElementTraversal-20080813/

After the SotD has been updated, we can start the process of  
scheduling the Director's call.


-Regards, Art Barstow


On Apr 14, 2009, at 9:30 PM, ext Ian Hickson wrote:


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: New CfC Re: [Selectors API] Call for Consensus - approve John Resig's tests

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'

New CfC Re: [Selectors API] Call for Consensus - approve John Resig's tests

[Charles McCathieNevile]

ages ago I  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.97&content-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: Selectors API

[Boris Zbarsky]

Maciej Stachowiak wrote:
Live lists will almost certainly be slower in the face of DOM mutation 
concurrent with iterating the list. I don't know of any reason things 
would be different in Gecko.


Yes, they would be.  The question is how much, and how often one 
iterates the whole list as opposed to just part of the list.


In the case of Selectors API especially, a fairly likely use case is to 
mutate the DOM while iterating the list - imagine finding all divs with 
a particular class name, attaching behavior, and then removing the class 
so that behavior is not accidentally added more than once.


For what it's worth, this specific use case has more or less O(N) 
behavior in Gecko (there is in fact an O(N^2) term with a very very 
small constant, but for most reasonable N (order of 10^4 or so) the O(N) 
terms dominate, I think).


One can experiment with this if desired by iterating document.anchors 
and removing href attributes, which is exactly the scenario above.


Complex selectors (involving indirect adjacent combinators for instance) would 
make things even worse - even DOM mutations that don't affect the 
contents of the list may force invalidation of any caches or else a 
complex calculation to prove they don't change the contents of the list.


This, though, is a very good point.  The set of mutations that could 
affect the list would indeed be much larger here than in most cases, and 
detection of when the list needs updating would be much more 
complicated...  So the implementation might not in fact be any simpler.


-Boris

Re: Selectors API

[Maciej Stachowiak]

On Mar 23, 2009, at 11:08 PM, Maciej Stachowiak wrote:



On Mar 23, 2009, at 7:30 AM, Boris Zbarsky wrote:


Anne van Kesteren wrote:

http://lists.w3.org/Archives/Public/public-webapi/2007Mar/0066.html
http://lists.w3.org/Archives/Public/public-webapi/2007Apr/0009.html
I read those. That was long after this was initially discussed  
though. And also around the time I stopped being the active editor  
of the specification.


Er, indeed.  Those seem to be discussion of ElementTraversal.

I was pretty sure I'd raised the same issue with Selectors API, but  
the W3C list search is crappy enough that I can't find the  
posts...  In fact, the only thread on the matter I can find is the  
"ACTION-87: Selectors API" thread (announcing that you plan to  
start working on the spec at) at <http://lists.w3.org/Archives/Public/public-webapi/2006Feb/0108.html 
>. Was that it?


In any case, the static implementation was considerably more  
complicated in Gecko, I suspect performance is a wash in most  
cases, though it's easy to create examples that are much faster  
with one or the other approach.


Live lists will almost certainly be slower in the face of DOM  
mutation concurrent with iterating the list. I don't know of any  
reason things would be different in Gecko.


In the case of Selectors API especially, a fairly likely use case is  
to mutate the DOM while iterating the list - imagine finding all  
divs with a particular class name, attaching behavior, and then  
removing the class so that behavior is not accidentally added more  
than once. This would be terrible for most conceivable live list  
implementations. Complex selectors (involving indirect adjacent  
combinators for instance) would make things even worse - even DOM  
mutations that don't affect the contents of the list may force  
invalidation of any caches or else a complex calculation to prove  
they don't change the contents of the list.


This is the reason I originally reported that live lists are likely  
to be a performance issue for some common uses of this API.


In fact, reading my old post I can see that I already explained the  
perf issues pretty well, including the performance downside of static  
lists, and the idea that you can mitigate this somewhat by a variant  
API that returns only the first match.


I'm still pretty sure you would get O(N^2) behavior in many cases of  
mutating while iterating a live querySelector list, even if live lists  
are easier to implement in Gecko.


Regards,
Maciej

Re: Selectors API

[Maciej Stachowiak]

On Mar 23, 2009, at 7:30 AM, Boris Zbarsky wrote:


Anne van Kesteren wrote:

http://lists.w3.org/Archives/Public/public-webapi/2007Mar/0066.html
http://lists.w3.org/Archives/Public/public-webapi/2007Apr/0009.html
I read those. That was long after this was initially discussed  
though. And also around the time I stopped being the active editor  
of the specification.


Er, indeed.  Those seem to be discussion of ElementTraversal.

I was pretty sure I'd raised the same issue with Selectors API, but  
the W3C list search is crappy enough that I can't find the posts...   
In fact, the only thread on the matter I can find is the "ACTION-87:  
Selectors API" thread (announcing that you plan to start working on  
the spec at) at <http://lists.w3.org/Archives/Public/public-webapi/2006Feb/0108.html 
>. Was that it?


In any case, the static implementation was considerably more  
complicated in Gecko, I suspect performance is a wash in most cases,  
though it's easy to create examples that are much faster with one or  
the other approach.


Live lists will almost certainly be slower in the face of DOM mutation  
concurrent with iterating the list. I don't know of any reason things  
would be different in Gecko.


In the case of Selectors API especially, a fairly likely use case is  
to mutate the DOM while iterating the list - imagine finding all divs  
with a particular class name, attaching behavior, and then removing  
the class so that behavior is not accidentally added more than once.  
This would be terrible for most conceivable live list implementations.  
Complex selectors (involving indirect adjacent combinators for  
instance) would make things even worse - even DOM mutations that don't  
affect the contents of the list may force invalidation of any caches  
or else a complex calculation to prove they don't change the contents  
of the list.


This is the reason I originally reported that live lists are likely to  
be a performance issue for some common uses of this API.


Regards,
Maciej

Re: Selectors API

[Anne van Kesteren]

On Mon, 23 Mar 2009 15:30:54 +0100, Boris Zbarsky  wrote:

Anne van Kesteren wrote:

http://lists.w3.org/Archives/Public/public-webapi/2007Mar/0066.html
http://lists.w3.org/Archives/Public/public-webapi/2007Apr/0009.html
 I read those. That was long after this was initially discussed though.  
And also around the time I stopped being the active editor of the  
specification.


Er, indeed.  Those seem to be discussion of ElementTraversal.


Oops.


I was pretty sure I'd raised the same issue with Selectors API, but the  
W3C list search is crappy enough that I can't find the posts...  In  
fact, the only thread on the matter I can find is the "ACTION-87:  
Selectors API" thread (announcing that you plan to start working on the  
spec at) at  
<http://lists.w3.org/Archives/Public/public-webapi/2006Feb/0108.html>.  
Was that it?


Yeah, I think  
http://lists.w3.org/Archives/Public/public-webapi/2006Feb/0129.html gives  
the basic argument. Still sounds reasonable today although it may not  
apply to all implementations.



In any case, the static implementation was considerably more complicated  
in Gecko, I suspect performance is a wash in most cases, though it's  
easy to create examples that are much faster with one or the other  
approach.


I personally would have preferred a live API. Too late now though.


--
Anne van Kesteren
http://annevankesteren.nl/

Re: Selectors API

[Boris Zbarsky]

Anne van Kesteren wrote:

http://lists.w3.org/Archives/Public/public-webapi/2007Mar/0066.html
http://lists.w3.org/Archives/Public/public-webapi/2007Apr/0009.html


I read those. That was long after this was initially discussed though. 
And also around the time I stopped being the active editor of the 
specification.


Er, indeed.  Those seem to be discussion of ElementTraversal.

I was pretty sure I'd raised the same issue with Selectors API, but the 
W3C list search is crappy enough that I can't find the posts...  In 
fact, the only thread on the matter I can find is the "ACTION-87: 
Selectors API" thread (announcing that you plan to start working on the 
spec at) at 
<http://lists.w3.org/Archives/Public/public-webapi/2006Feb/0108.html>. 
Was that it?


In any case, the static implementation was considerably more complicated 
in Gecko, I suspect performance is a wash in most cases, though it's 
easy to create examples that are much faster with one or the other approach.



-Boris

Re: Selectors API

[Anne van Kesteren]

On Mon, 23 Mar 2009 15:00:49 +0100, Boris Zbarsky  wrote:

Anne van Kesteren wrote:
 Interesting. I recall only hearing back from WebKit and Opera at the  
time I made the initial decision.


I recall that feedback as well, but assumed that this was the usual  
issue of some implementor feedback winning out when implementor feedback  
conflicted.  I'd be interested in finding out how I can make sure you  
actually see my future feedback; apparently there is a procedure other  
than posting in the relevant thread on the relevant mailing list for  
sending it in?


If you need a refresher on my comments on the matter, see:

http://lists.w3.org/Archives/Public/public-webapi/2007Mar/0066.html
http://lists.w3.org/Archives/Public/public-webapi/2007Apr/0009.html


I read those. That was long after this was initially discussed though. And  
also around the time I stopped being the active editor of the  
specification.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: Selectors API

[Boris Zbarsky]

Anne van Kesteren wrote:

On Mon, 23 Mar 2009 14:49:17 +0100, Boris Zbarsky  wrote:
Just as a point of record, I believe browser implementors were split 
on the issue (e.g. I think in Gecko live performance would be as good, 
if not better in many cases, as non-live performance.  I said so at 
the time as well).


Interesting. I recall only hearing back from WebKit and Opera at the 
time I made the initial decision.


I recall that feedback as well, but assumed that this was the usual 
issue of some implementor feedback winning out when implementor feedback 
conflicted.  I'd be interested in finding out how I can make sure you 
actually see my future feedback; apparently there is a procedure other 
than posting in the relevant thread on the relevant mailing list for 
sending it in?


If you need a refresher on my comments on the matter, see:

http://lists.w3.org/Archives/Public/public-webapi/2007Mar/0066.html
http://lists.w3.org/Archives/Public/public-webapi/2007Apr/0009.html

-Boris

Re: Selectors API

[Anne van Kesteren]

On Mon, 23 Mar 2009 14:49:17 +0100, Boris Zbarsky  wrote:
Just as a point of record, I believe browser implementors were split on  
the issue (e.g. I think in Gecko live performance would be as good, if  
not better in many cases, as non-live performance.  I said so at the  
time as well).


Interesting. I recall only hearing back from WebKit and Opera at the time  
I made the initial decision.



The argument that seemed to carry the day at the time is that live  
nodelists in general are an "anti-pattern" that shouldn't be foisted on  
authors.


There was that as well, yes.


--
Anne van Kesteren
http://annevankesteren.nl/

Re: Selectors API

[Boris Zbarsky]

Anne van Kesteren wrote:
I have been told that the reason for not having live collections is 
for performance, but I find that hard to understand.  The current live 
collections are much faster than their native javascript emulations, I 
can't see that getting a collection every time it is required will be 
faster than getting it once and using it many times.


This is in fact the reason they are static. Browser implementors 
indicated that doing this live would not perform well due to the 
relative complexity of Selectors.


Just as a point of record, I believe browser implementors were split on 
the issue (e.g. I think in Gecko live performance would be as good, if 
not better in many cases, as non-live performance.  I said so at the 
time as well).


The argument that seemed to carry the day at the time is that live 
nodelists in general are an "anti-pattern" that shouldn't be foisted on 
authors.


-Boris

Re: Selectors API

[Anne van Kesteren]

On Mon, 23 Mar 2009 11:32:56 +0100, Robert Green   
wrote:
I have been told that the reason for not having live collections is for  
performance, but I find that hard to understand.  The current live  
collections are much faster than their native javascript emulations, I  
can't see that getting a collection every time it is required will be  
faster than getting it once and using it many times.


This is in fact the reason they are static. Browser implementors indicated  
that doing this live would not perform well due to the relative complexity  
of Selectors.



--
Anne van Kesteren
http://annevankesteren.nl/

Selectors API

[Robert Green]

I wish to comment on the recommendation that NodeLists returned by  
the selectors API will be static.


I feel this removes one of the great benefits of live collections,  
that is, that once a collection is created, it is automatically  
updated by the browser itself.  This provides the possibility of  
creating a collection once and reusing it without having to create it  
again.


If the static NodeList model is maintained, it either means that the  
NodeList will have to be re-created every time a function wishes to  
access it, or separate native functions will have to be written to  
update the collection as the document is modified.  The second  
approach is clearly less than optimal as there may be functions  
modifying the document that the native methods aren't aware of.


I suspect there are two motivations for the choice of static  
collections:


1.  A number of popular javascript libraries have selector APIs that  
return static arrays, therefore a change to live collections would  
place them at a disadvantage


2. Novice script writers are confused by live collections

In regard to the first issue, I believe it can be worked around quite  
simply by those libraries providing an option to return live or  
static collections.  Then users have the choice of which type they want.


For the second issue, it is a matter of user (i.e. script programmer)  
education.  The current libraries hide live collections behind APIs  
that return static collections, often novices start out using a  
library and are never exposed to live NodeLists.  Also, there are  
only a limited number of live collections and their use has not been  
greatly exploited.


I have been told that the reason for not having live collections is  
for performance, but I find that hard to understand.  The current  
live collections are much faster than their native javascript  
emulations, I can't see that getting a collection every time it is  
required will be faster than getting it once and using it many times.


For your consideration.

Robert Green

Re: [Selectors API] Call for Consensus - approve John Resig's tests

[Erik Dahlström]

On Wed, 04 Mar 2009 11:00:43 +0100, Charles McCathieNevile  
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.97&content-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  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 @@
-
-
+http://www.w3.org/1999/xhtml";>
 
   
   selectorTest
@@ -222,7 +221,7 @@
 .foo..quux { background: red; color: yellow; }
 .bar. { background: red; color: yellow; }
   
-  
+  <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"] );
}
};
-  
+  ]]>
 
 
 http://www.w3.org/TR/selectors-api/";>Selectors API Test 
Suite
@@ -744,8 +747,8 @@
 
   
 
-
-
+
+
   
 
   
@@ -759,21 +762,21 @@
 
 
 
-
+
   
 
   
 
 
 
-
+
   
 
   
 
 
 
-
+
   
 
   
@@ -852,7 +855,7 @@
 
   
 
- 
+ 
   
 
   
@@ -889,7 +892,7 @@
  
 
 
- 
+ 
   
 
   
@@ -953,8 +956,8 @@
 
   
 
-
-
+
+
   
 
   
@@ -968,21 +971,21 @@
 
 
 
-
+
   
 
   
 
 
 
-
+
   
 
   
 
 
 
-
+
   
 
   
@@ -1061,7 +1064,7 @@
 
   
 
- 
+ 
   
 
   
@@ -1098,7 +1101,7 @@
  
 
 
- 
+ 
   
 
   
@@ -1151,7 +1154,7 @@



-   
+   http://www.w3.org/2000/svg";>
Example circle01 - circle filled with red and 
stroked with blue


@@ -1162,6 +1165,17 @@



+  http://www.w3.org/2000/svg"; xmlns:xlink="http://www.w3.org/1999/xlink"; 
version="1.1" id="svg4">
+
+  Example circle01 - circle filled with red and stroked 
with blue
+  
+  
+
+   
+
+
+
+  

 
jQuery Test Suite


Cheers
/Erik

[3] http://www.w3.org/TR/SVG11/struct.html#UseElement

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Re: [selectors-api] Test Suite Missing tests for Namespace Selectors

[Michael A. Puls II]

On Thu, 12 Mar 2009 10:47:53 -0400, Alexey Proskuryakov  wrote:



12.03.2009, в 17:19, Lachlan Hunt написал(а):


WebKit has a bug with the "|foo" selector.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/28

Opera and Firefox pass



This is actually a difference in createElementNS(null, "p") vs.  
createElementNS("", "p") behavior. I don't know whose bug it is, but in  
Firefox and Opera, empty and null namespace arguments both result in  
null namespace for the created element.


When createElement(null, "p") is used, this test passes in WebKit, too.


I filed  a while ago, which is at least 
one bug that has to do with the null or "" issue.

--
Michael

Re: [selectors-api] Test Suite Missing tests for Namespace Selectors

[Alexey Proskuryakov]

12.03.2009, в 18:01, Boris Zbarsky написал(а):

Make of this what you will.  But as I recall, the change in the "XML  
Namespaces" section was meant precisely to ensure that in JS passing  
"" for all namespace URIs would work exactly like passing null.


Sounds like webkit either implements createElementNS per DOM Core 2  
or has a buggy DOM Core 3 impl.



Thanks! I think that we want a proper DOM 3 Core implementation, filed  
.


I agree that the test should probably use null indeed.

- WBR, Alexey Proskuryakov

Re: [selectors-api] Test Suite Missing tests for Namespace Selectors

[Boris Zbarsky]

Lachlan Hunt wrote:
Interestingly, though, Opera has the opposite bug.  We fail when null is 
passed instead of "".


Fun.  Maybe the test should just test both.  ;)

-Boris

Re: [selectors-api] Test Suite Missing tests for Namespace Selectors

[Boris Zbarsky]

Alexey Proskuryakov wrote:
This is actually a difference in createElementNS(null, "p") vs. 
createElementNS("", "p") behavior. I don't know whose bug it is, but in 
Firefox and Opera, empty and null namespace arguments both result in 
null namespace for the created element.


Interesting question.  DOM 2 Core has this to say (section 1.1.8, XML 
Namespaces):


  Note that because the DOM does no lexical checking, the empty
  string will be treated as a real namespace URI in DOM Level 2
  methods. Applications must use the value null as the namespaceURI
  parameter for methods if they wish to have no namespace.

But DOM 3 Core (which I would assume supercedes that) says (section 
1.3.3, XML Namespaces):


  In programming languages where empty strings can be differentiated
  from null, empty strings, when given as a namespace URI, are
  converted to null. This is true even though the DOM does no lexical
  checking of URIs.

At the same time, the DOM 3 Core definition of createElementNS says:

  Per [XML Namespaces], applications must use the value null as the
  namespaceURI parameter for methods if they wish to have no
  namespace.

Make of this what you will.  But as I recall, the change in the "XML 
Namespaces" section was meant precisely to ensure that in JS passing "" 
for all namespace URIs would work exactly like passing null.


Sounds like webkit either implements createElementNS per DOM Core 2 or 
has a buggy DOM Core 3 impl.


In either case, the test should probably pass null, not "".

-Boris

Re: [selectors-api] Test Suite Missing tests for Namespace Selectors

[Lachlan Hunt]

Alexey Proskuryakov wrote:

12.03.2009, в 17:19, Lachlan Hunt написал(а):


WebKit has a bug with the "|foo" selector.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/28

Opera and Firefox pass


This is actually a difference in createElementNS(null, "p") vs. 
createElementNS("", "p") behavior. I don't know whose bug it is, but in 
Firefox and Opera, empty and null namespace arguments both result in 
null namespace for the created element.


When createElement(null, "p") is used, this test passes in WebKit, too.


DOM 3 Core states [1]:

  "In programming languages where empty strings can be differentiated
   from null, empty strings, when given as a namespace URI, are
   converted to null"

So, if I understand correctly, createElementNS("", "p") is effectively 
the same as createElementNS(null, "p").


Interestingly, though, Opera has the opposite bug.  We fail when null is 
passed instead of "".


[1] 
http://www.w3.org/TR/DOM-Level-3-Core/core.html#Namespaces-Considerations


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [selectors-api] Test Suite Missing tests for Namespace Selectors

[Alexey Proskuryakov]

12.03.2009, в 17:19, Lachlan Hunt написал(а):


WebKit has a bug with the "|foo" selector.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/28

Opera and Firefox pass



This is actually a difference in createElementNS(null, "p") vs.  
createElementNS("", "p") behavior. I don't know whose bug it is, but  
in Firefox and Opera, empty and null namespace arguments both result  
in null namespace for the created element.


When createElement(null, "p") is used, this test passes in WebKit, too.

- WBR, Alexey Proskuryakov

Re: [selectors-api] Test Suite Missing tests for Namespace Selectors

[Lachlan Hunt]

Lachlan Hunt wrote:

Hi,
  The Selectors API test suite is missing tests for the namespace 
selectors "|foo" and "*|foo".  Since they don't have prefixes that need 
to be resolved, they should be supported even without an NSResolver.


WebKit has a bug with the "|foo" selector.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/28

Opera and Firefox pass, and I believe all 3 pass the "*|foo" selector.

IE8 will throw a SYNTAX_ERR exception because it lacks support for the 
namespace selector syntax.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

[selectors-api] Test Suite Missing tests for Namespace Selectors

[Lachlan Hunt]

Hi,
  The Selectors API test suite is missing tests for the namespace 
selectors "|foo" and "*|foo".  Since they don't have prefixes that need 
to be resolved, they should be supported even without an NSResolver.


See brief IRC discussion about this:
http://krijnhoetmer.nl/irc-logs/whatwg/20090312#l-357

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [Selectors API] Call for Consensus - approve John Resig's tests

[Cameron McCormack]

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

[Cameron McCormack]

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

[Boris Zbarsky]

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

[Ian Hickson]

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

[Boris Zbarsky]

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

Re: [Selectors API] Call for Consensus - approve John Resig's tests

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'

Re: [Selectors API] Call for Consensus - approve John Resig's tests

[Boris Zbarsky]

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

[Ian Hickson]

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.97&content-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.   `._.-(,_..'--(,_..'`-.;.'

[selectors api] editorial trivia

[Charles McCathieNevile]

Hi Lachy, all

a couple of trivial editorial things for the spec, next time you revise it  
(hopefully for publication as PR :) ) - no need to make any changes while  
we are reviewing the spec anyway.


1. Copyright should be 2006-2009
2. Please add a note to the status section saying that some discussions on  
the spec were archived at public-webapi since it was previously developed  
by the Web API group (a forerunner to the WebApps group).


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

[Selectors API] Call for Consensus - approve John Resig's tests

[Charles McCathieNevile]

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.97&content-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] LCWD comments

[Lachlan Hunt]

Krzysztof Maczyński wrote:
This makes me even more sorry to have misled you (as you probably 
already know, since the issue is mentioned in e.g. 
http://lists.w3.org/Archives/Public/www-svg/2008Dec/0039.html) by 
asking to write "document" where the text should read "DOM". (D does 
stand for Document, but in fact there needn't be one. I tend to 
repeatedly forget that it's an API spec, not a CSS module. And it's 
perfectly useful for trees rooted at detached Element or 
DocumentFragment nodes.) Could you, please, revert this one change?


I think you're referring to the change made here at your request:
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0283.html

I have now reverted it.  This shouldn't be a problem since it's only a 
small editorial change.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [selectors-api] Test Suite Analysis (was: Call for Consensus - Selectors API to Candidate Rec)

[Jonas Sicking]

Just wanted to insert another thanks for going through these tests.
And to John Resig for writing up the tests. Really shows how valuable
tests are and how much they help with improving interoperability.

/ Jonas

On Thu, Feb 26, 2009 at 1:02 PM, Lachlan Hunt  wrote:
> 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] Test Suite Analysis (was: Call for Consensus - Selectors API to Candidate Rec)

[Cameron McCormack]

Lachlan Hunt:
> 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.

In http://www.w3.org/TR/WebIDL/#es-operations it requires a TypeError to
be thrown if the overload resolution algorithm
http://www.w3.org/TR/WebIDL/#dfn-overload-resolution-algorithm, which
ignores operations with more arguments than those passed to the
function) returns an empty set.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Re: [selectors-api] Test Suite Analysis (was: Call for Consensus - Selectors API to Candidate Rec)

[Lachlan Hunt]

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: Call for Consensus - Selectors API to Candidate Rec

[Travis Leithead]

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] LCWD comments

[Krzysztof Maczyński]

Yes, I'm satisfied with all the changes (although I still think it's useless 
and a bit risky of minor discrepancies to define document order when DOM Level 
3 Core is already normatively referenced), thank you for being so responsive 
and for the entirety of your effort on this spec.

This makes me even more sorry to have misled you (as you probably already know, 
since the issue is mentioned in e.g. 
http://lists.w3.org/Archives/Public/www-svg/2008Dec/0039.html) by asking to 
write "document" where the text should read "DOM". (D does stand for Document, 
but in fact there needn't be one. I tend to repeatedly forget that it's an API 
spec, not a CSS module. And it's perfectly useful for trees rooted at detached 
Element or DocumentFragment nodes.) Could you, please, revert this one change?
On the other hand, I won't object either if the concerned fragment ("the 
document tree or subtree in question") is left as is. After all, this is how 
most of your commenters at www-...@w3.org express these same concepts, with no 
big shadow of confusion within sight.

Re: [selectors-api] Stringifying undefined

[John Resig]

The test suite has been updated accordingly:
http://ejohn.org/apps/selectortest/

http://github.com/jeresig/selectortest/commit/4827dedddaea6fa0b70cfdaadeeafef0d732a753

--John



On Thu, Feb 19, 2009 at 6:40 AM, Lachlan Hunt  wrote:
> Jonas Sicking wrote:
>>
>> On Wed, Feb 18, 2009 at 7:34 AM, Anne van Kesteren 
>> wrote:
>>>
>>> So ideally what we do here is simply in line with how we plan to make all
>>> APIs that accept strings work (with exceptions).
>>
>> Yup, that's exactly what I've been arguing (both for this and for
>> other APIs). I think we should not have [Null=...] or [Undefined=...]
>> in there at all for now. Instead put some wording in that says that
>> we're doing whatever the default is for WebIDL, but that that isn't
>> fully locked down as of yet (since the spec is still a WD).
>
> I have now removed both the [Null] and [Undefined] extended attributes from
> the IDL and added a note advising implementers that WebIDL defines how to
> handle null and undefined.
>
> http://dev.w3.org/2006/webapi/selectors-api/#nodeselector
>
> Given the current WebIDL draft, this means they stringify to "null" and
> "undefined", respectively.
>
> --
> Lachlan Hunt - Opera Software
> http://lachy.id.au/
> http://www.opera.com/
>
>

Re: [selectors-api] Stringifying undefined

[Lachlan Hunt]

Jonas Sicking wrote:

On Wed, Feb 18, 2009 at 7:34 AM, Anne van Kesteren  wrote:

So ideally what we do here is simply in line with how we plan to make all
APIs that accept strings work (with exceptions).


Yup, that's exactly what I've been arguing (both for this and for
other APIs). I think we should not have [Null=...] or [Undefined=...]
in there at all for now. Instead put some wording in that says that
we're doing whatever the default is for WebIDL, but that that isn't
fully locked down as of yet (since the spec is still a WD).


I have now removed both the [Null] and [Undefined] extended attributes 
from the IDL and added a note advising implementers that WebIDL defines 
how to handle null and undefined.


http://dev.w3.org/2006/webapi/selectors-api/#nodeselector

Given the current WebIDL draft, this means they stringify to "null" and 
"undefined", respectively.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [selectors-api] Stringifying undefined

[Lachlan Hunt]

Jonas Sicking wrote:

On Fri, Feb 13, 2009 at 5:23 AM, Lachlan Hunt  wrote:

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?


When the NSResolver was in the spec, that's not how it worked.  If, when 
resolving a prefix, null or undefined was returned, then they were 
treated the same as the empty string so that an exception would be 
thrown.  It was only for the default namespace (prefix = "") that was 
allowed to have "" (or null or undefined) returned.



function nsresolver(ns) {
 uri = {xht: "http://www.w3.org/1999/xhtml";,
   svg: "http://www.w3.org/2000/svg";
   "": ""};
 return uri[ns];
}


If we do add namespace resolving again, it's not yet clear if the 
function is the solution that we will use. But if we did, then that 
makes it incredibly inconvenient for authors since, in most cases, they 
would have to remember to declare {"": ""} every time, along with 
whatever other prefixes they actually wanted to declare.


Anyway, I'd rather postpone this discussion of what NSResolver we use, 
if at all, till later when work on version 2 has begun.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/