This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
See discussion here: https://bugzilla.mozilla.org/show_bug.cgi?id=486002 IE, Firefox, and Opera all implement the DOM Level 3 Core spec. That means that for any two given disconnected nodes, they'll return either Node.DOCUMENT_POSITION_DISCONNECTED | Node.DOCUMENT_POSITION_PRECEDING | Node.DOCUMENT_POSITION_IMPLEMENTATION_SPECIFIC or Node.DOCUMENT_POSITION_DISCONNECTED | Node.DOCUMENT_POSITION_FOLLOWING | Node.DOCUMENT_POSITION_IMPLEMENTATION_SPECIFIC consistently, as long as each one's root node has no parent. (In practice, Gecko does a pointer comparison between pointers to the root nodes, where the pointer used is unique and stable for any given node. Probably IE/Opera are similar.) This is meant to be used for sorting arbitrary lists of nodes uniquely. In fact, jQuery exposes a function that does exactly that. But the current spec says to just return 0x01, which very well might break jQuery. jQuery relies on the sort being a total order because it passes a function based on it to JS' .sort() method, which has undefined behavior for bogus sort functions. In practice, the method is horrible enough (bitfields in JS!) that I don't think it's worth making it prettier. I say we should just spec it like DOM Level 3 Core. People can use .contains(), and we could add .isBefore()/.isAfter() methods to round it out if we want.
Anne and I discussed on IRC. Result: <annevk> I have to pack a few more things and go, maybe add a pointer to the bug about this discussion and just go with the DOM3 behavior for now <annevk> it's evil, but I can't think of anything better
So what about pure JavaScript implementations of the DOM? There was some vague plan to eventually move in that direction...
I don't think there's a problem for pure-JS impls per se, apart from the general difficulties of returning something consistent when you can't use the pointer value. Which is not specific to JS: it's a problem for any implementation that moves nodes in memory (e.g. might well be a problem for Servo)... I really wish I had better ideas here.
It's always possible to implement this feature by picking a random result when needed and then remembering it for future calls. In JS, you could do this for nodeA.compareDocumentPosition(nodeB): var rootA = nodeA; while (rootA.parentNode) { rootA = rootA.parentNode; } var rootB = nodeB; while (rootB.parentNode) { rootB = rootB.parentNode; } if (rootA != rootB) { if (rootA.randomValue === undefined) { rootA.randomValue = Math.random(); } if (rootB.randomValue === undefined) { rootB.randomValue = Math.random(); } return Node.NODE_DOCUMENT_POSITION_DISCONNECTED | Node.NODE_DOCUMENT_POSITION_IMPLEMENTATION_SPECIFIC | (rootA.randomValue < rootB.randomValue ? Node.DOCUMENT_POSITION_PRECEDING : Node.DOCUMENT_POSITION_FOLLOWING); } // Same-root case, not relevant here This would in practice probably not be impractically expensive, and I believe it meets the spec (unless Math.random() returns the same value twice).
https://github.com/whatwg/dom/tree/75f3a2e8cb623eed07765716671904405a5814e4 http://dom.spec.whatwg.org/#dom-node-comparedocumentposition
Updated test: https://dvcs.w3.org/hg/webapps/rev/03c049b18564 It doesn't yet try to test for consistency. That should maybe be a separate test file. (In reply to comment #5) > https://github.com/whatwg/dom/tree/75f3a2e8cb623eed07765716671904405a5814e4 Did you mean: https://github.com/whatwg/dom/commit/75f3a2e8cb623eed07765716671904405a5814e4 Blech, non-truncated commit id's . . .