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(contains(concat(' ', @class, ' '), ' character ') and

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.

Thanks for your help, Ken -- you've saved me some trial and error with
XPath syntax.


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

Reply via email to