[gravitypdf-bot]

Behaviour change. On a multi-element set, the traversal methods now return their results in jQuery's order. Before, the results were grouped by starting element.

$xml = '<r><a/><b/><c/><d/></r>';
qp($xml, 'c')->add('d')->prevAll();
// before: b, a, c   (grouped by starting element)
// after:  c, b, a   (reverse document order, as jQuery)

What jQuery does

I took the rules from jQuery 3.7.1's traversing.js. The table values come from running each call in jQuery 3.7.1 on jsdom. jQuery sorts only when the set has more than one element:

• parents, parentsUntil, prevAll and prevUntil use uniqueSort and then reverse, so they return reverse document order.
• next, prev, children and contents are in guaranteedUnique, so they are never sorted and keep the order of the starting elements.
• Everything else uses uniqueSort, which gives document order. That covers nextAll, nextUntil, siblings and parent. closest also sorts its results with uniqueSort.

Document: <r><i#a/><i#b/><i#c/><i#d/><i#e/></r>, and r > s#s1 > t#t1 > u#u1 and r > s#s2 > t#t2 > u#u2. The start sets are built in the order shown, not in document order.

Call	jQuery 3.7.1	before	after
[c, d].prevAll()	c, b, a	b, a, c	c, b, a
[c, e].prevUntil('#a')	d, c, b	b, d, c	d, c, b
[c, a].nextAll()	b, c, d, e	d, e, b, c	b, c, d, e
[c, a].nextUntil('#e')	b, c, d	d, b, c	b, c, d
[b, d].siblings()	a, b, c, d, e	a, c, d, e, b	a, b, c, d, e
[u2, u1].parent()	t1, t2	t2, t1	t1, t2
[u2, u1].closest('s')	s1, s2	s2, s1	s1, s2
[c, a].next()	d, b	d, b	d, b
[u2, u1].parents()	t2, s2, t1, s1, r	t2, s2, t1, s1, r	t2, s2, t1, s1, r

Results for a single starting element are unchanged.

What changed

Each traversal method names its order with one of two helpers, which filter by the optional selector, sort, and wrap the result:

Helper	Methods
inReverseDocumentOrder()	parents(), parentsUntil(), prevAll(), prevUntil()
inDocumentOrder()	nextAll(), nextUntil(), siblings(), parent(), closest()
(neither)	next(), prev(), which keep the order of the starting elements

walk(), the helper from #129, stays order-agnostic. sortReverseDocumentOrder() became the private sortDocumentOrder($nodes, $reverse) behind the two helpers, and still skips the sort for a single starting element. Filtering before sorting gives the same result as sorting first, because since #128 positional pseudo-classes count in document order whatever order the set is given in, and it sorts the smaller set.

Remaining differences from jQuery

• Positional selectors. jQuery filters a traversal's selector before it sorts, in walk order, so $('#e').prevAll(':first') is #d, the nearest sibling. QueryPath's positional pseudo-classes count in document order (jQuery positional pseudo-classes (:eq, :first, :lt, :gt, :odd, :even) index siblings instead of the match set; :eq(0) never matches #66), inside DOMTraverser, so prevAll(':first') is still #a. This PR does not change that, because it needs src/CSS/ changes; Positional selectors in prevAll(), parents() and the *Until() methods count in document order, not jQuery's walk order #134 tracks it. Since the count is done in document order, these results do not depend on the output ordering. Positional selectors in closest(), next() and the *Until() methods see a one-element set #118 pins them.
• parent($selector) still returns the nearest matching ancestor, where jQuery tests only the immediate parent. That is existing QueryPath behaviour.

Tests

• tests/Issues/Issue117Test.php covers each method on a multi-element set with an out-of-order start, plus the single-start case. Three of its five tests fail on main.
• In DOMQueryTest::testNextAllAndPrevAllFromOverlappingStarts, two expectations pinned the old grouped order. They now expect jQuery's.
• selectIds() and idList(), the helpers that build an out-of-order start set and list its IDs, live in QueryPathTests\TestCase, so Count positional *Until() stops across the document, as jQuery does #131's tests share them.
• vendor/bin/phpunit: 698 tests, 1948 assertions, 0 failures (1 skipped). composer run lint and composer run lint:min-php are clean.

Performance: the sort adds about 6 ms to nextAll() and prevAll() on a 4,000-item list (1.3 ms before, about 7 ms after).

Rebased onto #129

Rebased onto the updated #129, which moved ordering out of walk() and into the public methods; the ordering this PR first put at the end of walk() now lives in the two helpers above.

Fixes #117.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.14%. Comparing base (6ae6acf) to head (56a0b36).
⚠️ Report is 18 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main     #130      +/-   ##
============================================
+ Coverage     90.69%   91.14%   +0.44%     
- Complexity     1424     1434      +10     
============================================
  Files            25       26       +1     
  Lines          3170     3172       +2     
============================================
+ Hits           2875     2891      +16     
+ Misses          295      281      -14     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.