Andrew Dupont a écrit :
> On Feb 18, 9:45 pm, Ken Snyder <[EMAIL PROTECTED]> wrote:
>> Yes, it was very slow for me too with any of the "nth-" predicates.  
>> That nth routine relies on counting the number of previous siblings FOR
>> EVERY NODE.  I'm not sure if that is avoidable, but I've added the
>> corresponding xpath... see below.  The xpath syntax may need to be
>> reworked with previous-sibling or self, I'm not sure.   Or this may just
>> be a wrong path :)
> DomQuery sidesteps this by setting an expando "nodeIndex" property the
> first time it iterates through a group of child nodes.
>> I don't know how well you'll be able to implement a CSS "not()"
>> equivalent in XPath.  From what I could see, filtering out nodes in
>> XPath depends on the content of not().  Consider:
>> CSS3: div:not(#speech1)
>> XPath: .//[EMAIL PROTECTED]"speech1"]
>> CSS3: div.character:not([EMAIL PROTECTED])
>> XPath: .//div[contains(concat(' ', @class, ' '), ' character ') and
>> @id!='speech2']
> Luckily, "not" is a function in XPath.  It returns the opposite
> boolean of whatever it contains:
> .//div[not(@id="speech1")]
> .//div[not(contains(concat(' ', @class, ' '), ' character ') and
> @id='speech2')]
> Still a little tricky because of the placement of the brackets.  We
> might have to remove the brackets from Selector.xpath.* so that we can
> insert them properly based on the context of the predicate.  Also, I'm
> not even sure the second example qualifies as a "simple selector" the
> way the CSS3 spec defines it.

It doesn't.  As soon as you find yourself putting an 'and' in there,
you're doomed :-)  A simple selector is a SINGLE selector that is NOT a

Christophe Porteneuve a.k.a. TDD
"[They] did not know it was impossible, so they did it." --Mark Twain

You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at

Reply via email to