Re: ACTION-87: Selectors API

[Maciej Stachowiak]

On Jun 5, 2006, at 6:16 PM, liorean wrote:



On Mon, 05 Jun 2006 19:49:36 +1000, Anne van Kesteren  
<[EMAIL PROTECTED]>

wrote:
> I'm not really fond of matchOne()... Is there any precedence on  
this?


Not in JavaScript that I can think of. The only precedent case I can
think of for this example is String.prototype.match.


For this reason I think "match" is a fine name for the single-result  
case. The default of regexp matching (likely the most familiar other  
match operation) is to give a single result. If there is to be  
another name it should be matchFirst though, not matchOne, to be  
clear that it's returning the first match not just some arbitrarily  
chose one.



I am with Jonas on this - I don't think the name hurts or increases
confusion and it does slightly decrease it. But picking names is  
always

painful. We'll never get it perfectly right, but we can always get it
oh-so-very wrong :(


I tend to agree here. I don't like the suggested design of having
selectors be second class though. I think selectors are important
enough to have as first class objects, just like regex are.
Compile them to an object once, use multiple times. Little is lost in
performance for those using them once, but much is gained for those
using them over and over.


1) This can be added later, if such use cases turn out to be important.

2) I think you are overestimating the available performance gains.  
Parsing the selector string is will likely be by far the least  
expensive part of the match operation.


Regards,
Maciej

Re: ACTION-87: Selectors API

[liorean]

On Mon, 05 Jun 2006 19:49:36 +1000, Anne van Kesteren <[EMAIL PROTECTED]>
wrote:
> I'm not really fond of matchOne()... Is there any precedence on this?


Not in JavaScript that I can think of. The only precedent case I can
think of for this example is String.prototype.match.
That function does both though; it's the "global" flag on the regex
that determines whether to return just the first match or all of them.
And in my mind, that is a design error in regex in JavaScript, since
it's entirely plausible to want to use the same regex in both types of
matches.
This can be done by setting the global flag on the regex and using
RegExp.prototype.exec when a single match is desired and
String.prototype.match when an array of matches is wanted
Just the fact you have to change whether it's the regex or the string
that you call a method on - not to speak of the fact you need to set
the global flag on all regexes if you want this behaviour uniformly -
makes this an ugly solution to my eyes. The responsibility for solving
problems like this should lie on the functionality provider, not the
functionality consumer.

On 06/06/06, Charles McCathieNevile <[EMAIL PROTECTED]> wrote:

There is a precedent for any naming thing you care to consider, and some
you would prefer not to.


Indeed... I think my example highlights that.


I am with Jonas on this - I don't think the name hurts or increases
confusion and it does slightly decrease it. But picking names is always
painful. We'll never get it perfectly right, but we can always get it
oh-so-very wrong :(


I tend to agree here. I don't like the suggested design of having
selectors be second class though. I think selectors are important
enough to have as first class objects, just like regex are.
Compile them to an object once, use multiple times. Little is lost in
performance for those using them once, but much is gained for those
using them over and over.
It makes the code for a single use a little more complex, but not that
very much. It doesn't make much of a difference in code complexity for
those using them multiple times, and might even mean a reduction in
code complexity.
It does make up the question of whether the methods for matching
should be placed on the Selectors objects or the Document/Element
nodes though.
--
David "liorean" Andersson
http://liorean.web-graphics.com/>

Re: ACTION-87: Selectors API

[Charles McCathieNevile]

On Mon, 05 Jun 2006 19:49:36 +1000, Anne van Kesteren <[EMAIL PROTECTED]>  
wrote:

On Wed, 31 May 2006 00:11:23 +0200, Jonas Sicking <[EMAIL PROTECTED]>
 I'm not in love with having "match" in the name, but I could live  
with matchAll() and matchOne().


I like these names. Having short names is nice and all, but having  
clear ones is even better. Especially when the extra cost is just  
another three letters to type.


I'm not really fond of matchOne()... Is there any precedence on this?


There is a precedent for any naming thing you care to consider, and some  
you would prefer not to.


I am with Jonas on this - I don't think the name hurts or increases  
confusion and it does slightly decrease it. But picking names is always  
painful. We'll never get it perfectly right, but we can always get it  
oh-so-very wrong :(


cheers

chaals

--
Charles McCathieNevile [EMAIL PROTECTED]
  hablo español  -  je parle français  -  jeg lærer norsk
 Peek into the kitchen: http://snapshot.opera.com/

Re: ACTION-87: Selectors API

[Jonas Sicking]

Anne van Kesteren wrote:


On Wed, 31 May 2006 00:11:23 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote:
 I'm not in love with having "match" in the name, but I could live 
with matchAll() and matchOne().


I like these names. Having short names is nice and all, but having 
clear ones is even better. Especially when the extra cost is just 
another three letters to type.


I'm not really fond of matchOne()... Is there any precedence on this?


Don't know. But i'm not sure there is any precedence of having the 
un-postfixed method (in this case 'match') just return the first entry 
either. Usually the base method returns the full result and there are 
prefixed/postfixed methods that just return part of it.


/ Jonas

Re: ACTION-87: Selectors API

[Anne van Kesteren]

On Wed, 31 May 2006 00:11:23 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote:
 I'm not in love with having "match" in the name, but I could live with  
matchAll() and matchOne().


I like these names. Having short names is nice and all, but having clear  
ones is even better. Especially when the extra cost is just another  
three letters to type.


I'm not really fond of matchOne()... Is there any precedence on this?


--
Anne van Kesteren

Re: ACTION-87: Selectors API

[Anne van Kesteren]

On Wed, 31 May 2006 02:56:46 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote:

What we could maybe do though is to return a real ECMAScript array. I
actually like this idea a lot since that'll integrate much better with
scripts than a StaticNodeList would.


That makes a lot of sense. I support this.


 Heck yeah. Jonas: I think that would constitute a very good thing to  
put in the Bindings 4 DOM document. Of course, it's mean of me to  
suggest this means you have a new action item, but you can only blame  
yourself for having good ideas.


Yeah, that makes sense. I raised an action on me.


I'm fine with DOMArray. Let me know when there's something in TR/ I can  
point to.



--
Anne van Kesteren

Re: ACTION-87: Selectors API

[Jonas Sicking]

Robin Berjon wrote:


On May 30, 2006, at 15:55, Ian Hickson wrote:

On Tue, 30 May 2006, Jonas Sicking wrote:

What we could maybe do though is to return a real ECMAScript array. I
actually like this idea a lot since that'll integrate much better with
scripts than a StaticNodeList would.


That makes a lot of sense. I support this.


Heck yeah. Jonas: I think that would constitute a very good thing to put 
in the Bindings 4 DOM document. Of course, it's mean of me to suggest 
this means you have a new action item, but you can only blame yourself 
for having good ideas.


Yeah, that makes sense. I raised an action on me.

/ Jonas

Re: ACTION-87: Selectors API

[Robin Berjon]

On May 30, 2006, at 15:55, Ian Hickson wrote:

On Tue, 30 May 2006, Jonas Sicking wrote:

What we could maybe do though is to return a real ECMAScript array. I
actually like this idea a lot since that'll integrate much better  
with

scripts than a StaticNodeList would.


That makes a lot of sense. I support this.


Heck yeah. Jonas: I think that would constitute a very good thing to  
put in the Bindings 4 DOM document. Of course, it's mean of me to  
suggest this means you have a new action item, but you can only blame  
yourself for having good ideas.


--
Robin Berjon
   Senior Research Scientist
   Expway, http://expway.com/

Re: ACTION-87: Selectors API

[Ian Hickson]

On Tue, 30 May 2006, Jonas Sicking wrote:
> > 
> > - Third, NodeLists being live means you cannot manually manipulate 
> > them. StaticNodeLists don't have this problem. Since they are not 
> > live, manipulation of them should not be a problem. This means array 
> > functionality such as sort, push, pop that would simply not make sense 
> > on a NodeList would make perfect sense on a StaticNodeList.
> 
> I don't want us to define a new array when ECMAScript has a perfectly 
> good one. That is just a lot more work for everyone involved.
> 
> What we could maybe do though is to return a real ECMAScript array. I 
> actually like this idea a lot since that'll integrate much better with 
> scripts than a StaticNodeList would.

That makes a lot of sense. I support this.

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

Re: ACTION-87: Selectors API

[Jonas Sicking]

liorean wrote:


On 13/05/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote:

On Sat, 13 May 2006 21:08:26 +0200, liorean <[EMAIL PROTECTED]> wrote:
> And StaticNodeList looks to me to be pretty array-like.

Well, if StaticNodeList looks that way NodeList would look that way too
and I'd therefore suggest raising that on [EMAIL PROTECTED] instead. Note
that I don't really want to be defining StaticNodeList in the first 
place.


Not quite. NodeList are, in some ways, array-like. But StaticNodeList
is more array-like, for several reasons:

- First of all, I think StaticNodeList would be implemented as an
actual list or hash table, not as filters used on the live node tree.
This specifically because it's not supposed to be affected by changes
in the node tree. This means they are considerably different under the
hood.

- Second, manipulating the DOM using elements gotten from looping
through a NodeList will have effects on that NodeList during the loop.
Removals, reparentings, insertions etc, may affect the NodeList.
StaticNodeList will not be affected by changes to the DOM. This means
the different mapping functions may have very bizzarre side effects on
NodeLists that they would not have on StaticNodeLists.

- Third, NodeLists being live means you cannot manually manipulate
them. StaticNodeLists don't have this problem. Since they are not
live, manipulation of them should not be a problem. This means array
functionality such as sort, push, pop that would simply not make sense
on a NodeList would make perfect sense on a StaticNodeList.


I don't want us to define a new array when ECMAScript has a perfectly 
good one. That is just a lot more work for everyone involved.


What we could maybe do though is to return a real ECMAScript array. I 
actually like this idea a lot since that'll integrate much better with 
scripts than a StaticNodeList would.


We could define a new top-level object like DOMArray and then let that 
map to different things in ECMAScript and Java.


/ Jonas

Re: ACTION-87: Selectors API

[Jonas Sicking]

Anne van Kesteren wrote:


On Wed, 17 May 2006 15:35:24 +0200, Jim Ley <[EMAIL PROTECTED]> wrote:

The shortest name should represent the most efficient method imho.


Crazy notion, names should be clear, not short for efficiency.


The point was that if the more efficient one of the  two actually had a 
longer name, people would probably use the shorter name and just take 
the first node using [0] or whatever can be used for that in their 
language binding.


I agree that is a risk, though not really a huge concern. Convenience 
methods are often slower than more complex syntax. Once a script gets so 
slow that performance matters (which often never is the case when it 
comes to web scripts) then they could switch to the more optimized methods.


All we'd need to do for this to work is to describe in the spec which 
method is likely to be faster.


/ Jonas

Re: ACTION-87: Selectors API

[Jonas Sicking]

Robin Berjon wrote:


On May 17, 2006, at 16:02, Lachlan Hunt wrote:

I don't know anyone who thinks efficiency is proportional to the length


I get a lot of spam that says it is, but their conformance criteria are 
unclear.


I'm not in love with having "match" in the name, but I could live with 
matchAll() and matchOne().


I like these names. Having short names is nice and all, but having clear 
ones is even better. Especially when the extra cost is just another 
three letters to type.


/ Jonas

Re: ACTION-87: Selectors API

[Anne van Kesteren]

On Wed, 17 May 2006 15:35:24 +0200, Jim Ley <[EMAIL PROTECTED]> wrote:

The shortest name should represent the most efficient method imho.


Crazy notion, names should be clear, not short for efficiency.


The point was that if the more efficient one of the  two actually had a  
longer name, people would probably use the shorter name and just take the  
first node using [0] or whatever can be used for that in their language  
binding.



--
Anne van Kesteren

Re: ACTION-87: Selectors API

[Robin Berjon]

On May 17, 2006, at 16:02, Lachlan Hunt wrote:
I don't know anyone who thinks efficiency is proportional to the  
length


I get a lot of spam that says it is, but their conformance criteria  
are unclear.


I'm not in love with having "match" in the name, but I could live  
with matchAll() and matchOne().


--
Robin Berjon
   Senior Research Scientist
   Expway, http://expway.com/

Re: ACTION-87: Selectors API

[Lachlan Hunt]

Anne van Kesteren wrote:

* match("foo")[0] (when match() would return a list)
* matchOne("foo")
* matchFirst("foo")

The shortest name should represent the most efficient method imho.


I don't know anyone who thinks efficiency is proportional to the length 
of the function name.


--
Lachlan Hunt
http://lachy.id.au/

Re: ACTION-87: Selectors API

[Jim Ley]

"Anne van Kesteren" <[EMAIL PROTECTED]>
On Wed, 17 May 2006 15:19:46 +0200, Lachlan Hunt
<[EMAIL PROTECTED]> wrote:
I like match() too because it's much shorter than 
getElementsBySelector(),


Right... :-)


Shortness should not be a motivatio, clear and unambiguous is the aim for 
DOM names, if you want short in your application, wrap the function, it's 
simple.



The shortest name should represent the most efficient method imho.


Crazy notion, names should be clear, not short for efficiency.

Jim. 

Re: ACTION-87: Selectors API

[Anne van Kesteren]

On Wed, 17 May 2006 15:19:46 +0200, Lachlan Hunt  
<[EMAIL PROTECTED]> wrote:
I like match() too because it's much shorter than  
getElementsBySelector(),


Right... :-)


but I think the fact that it only returns a single node is confusing and  
that, in most cases, authors would want the whole collection, not just  
the first match.  I think it would be better if the methods were:


[...]


In that case you have this issue:

* match("foo")[0] (when match() would return a list)
* matchOne("foo")
* matchFirst("foo")

The shortest name should represent the most efficient method imho.



What's wrong with using:

var selectorMatches = document.matchAll('#bleh elm3', resolver);

There may still be use cases for matching a sub tree, so it may be worth  
extending the Element interface too, but all the ones I can think of can  
be handled by simply writing a more specific selector.


Yeah, except when you get a random element back like event.target. And  
even in that case you can probably give the event some random ID in most  
cases but it's not really flexible.



--
Anne van Kesteren

Re: ACTION-87: Selectors API

[Lachlan Hunt]

Anne van Kesteren wrote:

On Wed, 17 May 2006 06:29:54 +0200, liorean <[EMAIL PROTECTED]> wrote:

   * Several people have raised issues with naming the methods match and
matchAll as those might suggest a boolean return value. Alternate 
suggestions

have been select and selectAll.


For ECMAScript, I think "match" is a fine choice of verb and is
consistent. For the closest comparison, regex 'match' isn't boolean.


Sure, I like match() as well. Mostly because it's short and simple, but 
there were some concerns raised.


I like match() too because it's much shorter than 
getElementsBySelector(), but I think the fact that it only returns a 
single node is confusing and that, in most cases, authors would want the 
whole collection, not just the first match.  I think it would be better 
if the methods were:


interface DocumentSelector {
  StaticNodeList match(in DOMString selectors, in XPathNSResolver 
nsresolver);

  Node matchOne(in DOMString selectors, in XPathNSResolver nsresolver);
};

Or possibly matchFirst() instead.



/.../






/.../


var
selectorMatches=document.getElementById('bleh').matchAll(':root
elm3',resolver);


What's wrong with using:

var selectorMatches = document.matchAll('#bleh elm3', resolver);

There may still be use cases for matching a sub tree, so it may be worth 
extending the Element interface too, but all the ones I can think of can 
be handled by simply writing a more specific selector.


--
Lachlan Hunt
http://lachy.id.au/

Re: ACTION-87: Selectors API

[Anne van Kesteren]

On Wed, 17 May 2006 06:29:54 +0200, liorean <[EMAIL PROTECTED]> wrote:

   * Several people have raised issues with naming the methods match and
matchAll as those might suggest a boolean return value. Alternate  
suggestions

have been select and selectAll.


For ECMAScript, I think "match" is a fine choice of verb and is
consistent. For the closest comparison, regex 'match' isn't boolean.


Sure, I like match() as well. Mostly because it's short and simple, but  
there were some concerns raised.




I think there's some confusion here about what is requested and what
you think is requested. What I personally mean when I want to have a
way to ask for all nodes in a NodeList that matches a selector or all
nodes in an element's subtree that matches a selector doesn't effect
the scope of the selectors. For example:


/.../






/.../


var
selectorMatches=document.getElementById('bleh').matchAll(':root
elm3',resolver);

This selectorMatches variable would be StaticNodeList of both nodes in
the subtree below #bleh that match the selector. It would not at all
affect the scoping of the selector (':root' still matches the 'doc'
element, for example). It would only affect a single thing: it would
ask for matches in a subtree of the document instead of all matches in
the entire document tree.


That would be a different request yes. This issue was not really coming  
from you though... I guess I could add it, but it probably won't make the  
first public Working Draft.




At least one issue more that I think should be added:

Currently you can ask "gimme all matches in the document against this
selector" but you can't ask "I've got this element handle (from
event.target or whereever). Does this very element match this
selector?". Even if you did add 'match' and 'matchAll' on the Element
interface, those don't make it any easier to get an answer to that
question. So, some type of equivalent to regex.test(string) would be
immensely useful.


We already discussed that and imho it's out of scope for this version.



(It can also be noted that this is the only functionality really
needed. Traversal is already in the DOM1, so that is not the problem.
What is missing is the functionality of asking for if an element
matches a selector.)


Well yeah, and XPath is in DOM Level 3... This is more about providing a  
simple way of selecting a bunch of modes based on a group of selectors.  
This functionality is already provided in libraries and people would find  
this really useful. (As would I!)



--
Anne van Kesteren

Re: ACTION-87: Selectors API

[liorean]

Some comments on the outstanding issues:


1.3 Outstanding Issues
This section is non-normative.

The draft has several outstanding issues that either need to be

addressed in one

way or another at some point:

   * Several people have raised issues with naming the methods match and
matchAll as those might suggest a boolean return value. Alternate suggestions
have been select and selectAll.


For ECMAScript, I think "match" is a fine choice of verb and is
consistent. For the closest comparison, regex 'match' isn't boolean.
Regex 'match' returns an array of the matched data  - data which may
be either detail about a single match OR a list of all full matches
depending on whether the regex has a global flag.
Regex uses the verb 'test' for the boolean matching.


   * There was at least one request for scoped selectors. For example, being 
able
to do event.target.match() or in other words allowing the methods on Element
nodes. Given that Selectors itself has no notion of scoped selectors

this might be

difficult to define and is perhaps better delayed until the CSS WG has defined
scoped selectors.


I think there's some confusion here about what is requested and what
you think is requested. What I personally mean when I want to have a
way to ask for all nodes in a NodeList that matches a selector or all
nodes in an element's subtree that matches a selector doesn't effect
the scope of the selectors. For example:

   
   /.../
   
   
   
   
   
   
   /.../
   

   var
   selectorMatches=document.getElementById('bleh').matchAll(':root
elm3',resolver);

This selectorMatches variable would be StaticNodeList of both nodes in
the subtree below #bleh that match the selector. It would not at all
affect the scoping of the selector (':root' still matches the 'doc'
element, for example). It would only affect a single thing: it would
ask for matches in a subtree of the document instead of all matches in
the entire document tree.


   * It would be nice if extensibility was addressed by DOM Level 3 Core or a
separate specification that all DOM specifications could reuse.
   * Need to look into XPathNSResolver and the default namespace.
   * If DOM Level 3 Core gets errata we might be able to get away with not 
having
a new interface at all for NodeList (StaticNodeList), but just say

that the object

implementing the NodeList interface is not live.


At least one issue more that I think should be added:

Currently you can ask "gimme all matches in the document against this
selector" but you can't ask "I've got this element handle (from
event.target or whereever). Does this very element match this
selector?". Even if you did add 'match' and 'matchAll' on the Element
interface, those don't make it any easier to get an answer to that
question. So, some type of equivalent to regex.test(string) would be
immensely useful.

(It can also be noted that this is the only functionality really
needed. Traversal is already in the DOM1, so that is not the problem.
What is missing is the functionality of asking for if an element
matches a selector.)
--
David "liorean" Andersson
http://liorean.web-graphics.com/>

Re: ACTION-87: Selectors API

[Anne van Kesteren]

On Mon, 15 May 2006 01:22:21 +0200, liorean <[EMAIL PROTECTED]> wrote:

I just have a look at the XPathNSResolver interface.

In the Selectors spec, the selector "elm" is equivalent to "*|elm" in
the case of a missing default namespace, but "ns|elm" where "ns" is
the default namespace if a default namespace is declared.

The XPathNSResolver interface specifically states that it must never
be  called with a null or empty argument. I imagine the Selectors API
would want to be able to send a null argument as a way to ask for the
default namespace, or be given some equivalent functionality.


During our F2F I discussed this Jonas (he's the editor of DOM Level 3  
XPath) and we're considering something like that, yes. Not sure yet if DOM  
Level 3 XPath will allow it and say that for XPath related methods UAs  
MUST do nothing or that Selectors API widens the scope of it. I hope the  
former, but we'll see that when we get there. Thanks for raising it on the  
list.



--
Anne van Kesteren

Re: ACTION-87: Selectors API

[liorean]

I just have a look at the XPathNSResolver interface.

In the Selectors spec, the selector "elm" is equivalent to "*|elm" in
the case of a missing default namespace, but "ns|elm" where "ns" is
the default namespace if a default namespace is declared.

The XPathNSResolver interface specifically states that it must never
be  called with a null or empty argument. I imagine the Selectors API
would want to be able to send a null argument as a way to ask for the
default namespace, or be given some equivalent functionality.
--
David "liorean" Andersson
http://liorean.web-graphics.com/>

Re: ACTION-87: Selectors API

[Anne van Kesteren]

On Wed, 22 Mar 2006 15:45:21 +0100, Jim Ley <[EMAIL PROTECTED]> wrote:

Fair enough, here are the requirements for the name:

* short
* simple


Why are these requirements for the name, no other DOM names are short  
and simple, they're clear and unambiguous, I'd say they were the  
requirements. If people want to use shorter names they understand in  
their closed world the $x() approach is perfectly simple for them  
(although discouraged by ECMA of course).


This has been noted as an open issue.



The reason is performance.


Then one 1 method with an optional limit is ,uch better, it optimises  
for all situations when the author knows how many they're interested in,  
rather than 1 special case.  I don't see why the 1 case is that much  
more special than the N case - as I say gEBI meets most of the 1 cases.


The 1 case returns a Node as opposed to a StaticNodeList.


--
Anne van Kesteren

Re: ACTION-87: Selectors API

[liorean]

On 13/05/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote:

On Sat, 13 May 2006 21:08:26 +0200, liorean <[EMAIL PROTECTED]> wrote:
> And StaticNodeList looks to me to be pretty array-like.

Well, if StaticNodeList looks that way NodeList would look that way too
and I'd therefore suggest raising that on [EMAIL PROTECTED] instead. Note
that I don't really want to be defining StaticNodeList in the first place.


Not quite. NodeList are, in some ways, array-like. But StaticNodeList
is more array-like, for several reasons:

- First of all, I think StaticNodeList would be implemented as an
actual list or hash table, not as filters used on the live node tree.
This specifically because it's not supposed to be affected by changes
in the node tree. This means they are considerably different under the
hood.

- Second, manipulating the DOM using elements gotten from looping
through a NodeList will have effects on that NodeList during the loop.
Removals, reparentings, insertions etc, may affect the NodeList.
StaticNodeList will not be affected by changes to the DOM. This means
the different mapping functions may have very bizzarre side effects on
NodeLists that they would not have on StaticNodeLists.

- Third, NodeLists being live means you cannot manually manipulate
them. StaticNodeLists don't have this problem. Since they are not
live, manipulation of them should not be a problem. This means array
functionality such as sort, push, pop that would simply not make sense
on a NodeList would make perfect sense on a StaticNodeList.




I do see two notable differences between StaticNodeList and ECMAScript
Array though:

- NodeList is naturally dense, so StaticNodeList would have to force
denseness too. Array is sparse. This means that what happens when the
user tries assigning to random indices larger than the length; or
removing elements in the middle of the StaticNodeList; or setting the
length to a value larger than the current length; would need to be
defined in a way that makes sense in the ECMAScript bindings.

- NodeLists only contain Node objects, so the same would have to be
true for StaticNodeList. Arrays may contain any type of JavaScript
object. This means what happens if the user tries to add a non-Node
object to the StaticNodeList would have to be defined in the
ECMAScript bindings.


One possible solution to these problems:
- If trying to insert a non-Node in the StaticNodeList, throw the
appropriate RunTime error.
- If trying to delete any index smaller than the length of the
StaticNodeList, throw the appropriate RunTime error. (might have to be
length-1, to allow for removing the last element in StaticNodeList)
- If trying to assign to an index larger than the length of the
StaticNodeList, thow the appropriate RunTime arror.
- If trying to assign a value larger than the current length of the
StaticNodeList to the length property, throw the appropriate RunTime
error.
--
David "liorean" Andersson
http://liorean.web-graphics.com/>

Re: ACTION-87: Selectors API

[Anne van Kesteren]

On Sat, 13 May 2006 21:08:26 +0200, liorean <[EMAIL PROTECTED]> wrote:

I do think you're unnecessarily limiting the use of the Selectors API
in the current draft by only allowing selector matching on the subtree
of the document node though. The same way you might want to use
getElementsByTagName not on the document node but on some deeper
element node, you might want to do selectors matching on the subtree
of a deeper element node instead of on the entire tree.


The Selectors specification doesn't define scoped selectors as noted in  
"Outstanding Issues." Not sure if this specification should define that  
for them. This has been noted though.


I'm not really decided about the more general issue: A group of selectors  
becoming some kind of object instead of a string. I can see it would have  
some advantages for the simple use cases this draft was written for it's  
not really needed.




3. Letting StaticNodeList inherit from Array and NodeList not is not an
option. They have to be identical. Hopefully DOM Level 3 Core gets  
errata

to say that only some object implementing the NodeList interface is live
and not all objects implementing NodeList (well, it currently says
something even vaguer if I remember correctly) so we can drop
StaticNodeList and just define that the object is static.


Well, does it matter if StaticNodeList in the ECMAScript bindings is
defined to have the Array.prototype as it's prototype object instead
of the Object.prototype? That doesn't change the interface itself,
it's just a question of ECMAScript bindings. The reason one would want
this is of course that one might want to use array methods such as
Array.prototype.sort, Array.prototype.map or Array.prototype.filter on
the returns from the selector match without having to jump through
hoops to do so. At least the ECMAScript defined Array.prototype
methods are written to be generic and work on any array-like object, I
hope the Mozilla JavaScript 1.6 Array extras are written that way too.
And StaticNodeList looks to me to be pretty array-like.


Well, if StaticNodeList looks that way NodeList would look that way too  
and I'd therefore suggest raising that on [EMAIL PROTECTED] instead. Note  
that I don't really want to be defining StaticNodeList in the first place.



--
Anne van Kesteren

Re: ACTION-87: Selectors API

[liorean]

On 13/05/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote:

On Sat, 13 May 2006 05:49:45 +0200, liorean <[EMAIL PROTECTED]> wrote:
> I've written some commentary on the Selectors API draft on WebGraphics.
>
> http://web-graphics.com/2006/05/12/javascript-and-selectors/>

1. I'm aware how selectors work in browsers and that that's different from
how they'd work here, but there was no pushback from implementors given
that this is something authors want to use.


Actually, a large part of that blog entry was written more to the
WebGraphics audience than to you. I trust you know how these things
work in browsers quite a bit more in detail than I do.


Note also that you don't get live collections.


Might be, I have only a little knowledge of how they are implemented
in browsers. I can see a number of different solutions to how you
could implement them, depending a bit on whether they have to be
thread safe or not.

However, I do know Jens Lindström's explanation of how Opera does them
not as actual lists but as filters for the node tree, doing traversal
from first, last, or last returned node.


2. I'm not convinced it should be a native data type in ECMAScript. It
operates on the DOM which is not native to ECMAScript either. Having an
object which implements some selector interface on which you can perform
node tests seems like an interesting idea, but is currently outside the
scope of this specification. If there is enough interest though it seems
certainly we should look into.


Well a DOM node might not be cunstrucable using the following:

   var nd = new Node();

But DOM nodes do exist as first class objects in ECMAScript. I
couldn't care less about whether it's
DOMImplementation.createSelectors(string,nsresolver) or new
Selectors(string,nsresolver), but I do think they should be first
class objects that are not bound to the document.

I'm more saying this because I think it makes more sense to build an
object from the selectors string and the nsresolver once, and reuse
that object, than to reevaluate the selector every time you have to
use it.

Also, I'm not arguing for any specific way of applying them.
document.match(selectors) or selectors.search(document) isn't
important to me. I just wrote it as methods on the selectors object
because then searching subtree could take a node which is either a
document or an element with one single interface definition, instead
of having to replicate the same on both document and element
interfaces.

I do think you're unnecessarily limiting the use of the Selectors API
in the current draft by only allowing selector matching on the subtree
of the document node though. The same way you might want to use
getElementsByTagName not on the document node but on some deeper
element node, you might want to do selectors matching on the subtree
of a deeper element node instead of on the entire tree.


3. Letting StaticNodeList inherit from Array and NodeList not is not an
option. They have to be identical. Hopefully DOM Level 3 Core gets errata
to say that only some object implementing the NodeList interface is live
and not all objects implementing NodeList (well, it currently says
something even vaguer if I remember correctly) so we can drop
StaticNodeList and just define that the object is static.


Well, does it matter if StaticNodeList in the ECMAScript bindings is
defined to have the Array.prototype as it's prototype object instead
of the Object.prototype? That doesn't change the interface itself,
it's just a question of ECMAScript bindings. The reason one would want
this is of course that one might want to use array methods such as
Array.prototype.sort, Array.prototype.map or Array.prototype.filter on
the returns from the selector match without having to jump through
hoops to do so. At least the ECMAScript defined Array.prototype
methods are written to be generic and work on any array-like object, I
hope the Mozilla JavaScript 1.6 Array extras are written that way too.
And StaticNodeList looks to me to be pretty array-like.
--
David "liorean" Andersson
http://liorean.web-graphics.com/>

Re: ACTION-87: Selectors API

[Anne van Kesteren]

On Sat, 13 May 2006 05:49:45 +0200, liorean <[EMAIL PROTECTED]> wrote:

I've written some commentary on the Selectors API draft on WebGraphics.

http://web-graphics.com/2006/05/12/javascript-and-selectors/>


1. I'm aware how selectors work in browsers and that that's different from  
how they'd work here, but there was no pushback from implementors given  
that this is something authors want to use. Note also that you don't get  
live collections.


2. I'm not convinced it should be a native data type in ECMAScript. It  
operates on the DOM which is not native to ECMAScript either. Having an  
object which implements some selector interface on which you can perform  
node tests seems like an interesting idea, but is currently outside the  
scope of this specification. If there is enough interest though it seems  
certainly we should look into.


3. Letting StaticNodeList inherit from Array and NodeList not is not an  
option. They have to be identical. Hopefully DOM Level 3 Core gets errata  
to say that only some object implementing the NodeList interface is live  
and not all objects implementing NodeList (well, it currently says  
something even vaguer if I remember correctly) so we can drop  
StaticNodeList and just define that the object is static.



--
Anne van Kesteren

Re: ACTION-87: Selectors API

[liorean]

I've written some commentary on the Selectors API draft on WebGraphics.

http://web-graphics.com/2006/05/12/javascript-and-selectors/>
--
David "liorean" Andersson
http://liorean.web-graphics.com/>

Re: ACTION-87: Selectors API

[Anne van Kesteren]

On Wed, 22 Mar 2006 20:25:18 +0100, Maciej Stachowiak <[EMAIL PROTECTED]>  
wrote:
* IMHO the method should not raise an exception when the selector  
contains a pseudo-element. It should would return an empty list.


Given that it per definition only returns Element nodes I don't see why  
it shouldn't raise an exception.


I think exceptions should be reserved for actual syntax errors, not for  
selectors that can't match an element. I'm sure there are other ways  
besides pseudo-elements to make a selector that can't match anything.


The current specification  
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/draft/selectors-api.htm?content-type=text/html;%20charset=utf-8  
should reflect this.



--
Anne van Kesteren

Re: ACTION-87: Selectors API

[Anne van Kesteren]

* Authors are no longer required to use null or omit
  the argument if they don't use namespaces;
* TYPE_MISMATCH_ERR is gone;
* Security considerations section talks about one
  potential problem instead of the only problem.



Anyway, these are all nit-picking details, which are generally up to the
editor to worry about, so I'll stop now. :-)


Well, they are quite useful, thanks!


--
Anne van Kesteren