19555 2012-10-16 15:21:06 +0000 Node.getDocumentPosition should return 0x23 or 0x25 for disconnected nodes, not 0x01 2012-11-10 19:04:13 +0000 1 1 1 Unclassified WebAppsWG DOM unspecified All All RESOLVED FIXED P2 normal --- 13044 1 ayg annevk bzbarsky mike Ms2ger www-dom public-webapps-bugzilla oldest_to_newest 76396 0 ayg 2012-10-16 15:21:06 +0000 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. 77201 1 ayg 2012-10-28 12:25:56 +0000 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 77202 2 annevk 2012-10-28 13:13:42 +0000 So what about pure JavaScript implementations of the DOM? There was some vague plan to eventually move in that direction... 77234 3 bzbarsky 2012-10-29 01:22:07 +0000 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. 77406 4 ayg 2012-10-30 12:08:57 +0000 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). 78122 5 annevk 2012-11-09 15:34:03 +0000 https://github.com/whatwg/dom/tree/75f3a2e8cb623eed07765716671904405a5814e4 http://dom.spec.whatwg.org/#dom-node-comparedocumentposition 78179 6 ayg 2012-11-10 19:04:13 +0000 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 . . .