I played with different XPath queries with XPather (works only with older firefox versions) and notice a difference between the results from the following queries
This one shows some results
//div[descendant::table/descendant::td[4]]
This one lists empty list
//div[//table//td[4]]
Are they different due to some rules or it's just misbehavior of particular implementation of XPath interpreter? (Seems like used from FF engine, XPather is just an excellent simple GUI for querying)
解决方案
With XPath 1.0 // is an abbreviation for /descendant-or-self::node()/ so your first path is /descendant-or-self::node()/div[descendant::table/descendant::td[4]] while the second is rather different with /descendant-or-self::node()/div[/descendant-or-self::node()/table/descendant-or-self::node()/td[4]]. So the major difference is that inside your first predicate you look down for descendants relative to the div element while in the second predicate you look down for descendants from the root node / (also called the document node).You might want //div[.//table//td[4]] for the second path expression to come closer to the first one.
With that sample the path //div[descendant::table/descendant::td[4]] selects the div element as it has a table child which has a fourth td descendant.
However with //div[.//table//td[4]] we look for //div[./descendant-or-self::node()/table/descendant-or-self::node()/td[4]] which is short for //div[./descendant-or-self::node()/table/descendant-or-self::node()/child::td[4]] and there is no element having a fourth td child element.
I hope that explains the difference, if you use //div[.//table/descendant::td[4]] then you should get the same result as with your original form.