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
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
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to firstname.lastname@example.org
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at