13464 2011-07-30 14:16:35 +0000 Add Element.contains()? 2011-09-07 14:28:52 +0000 1 1 1 Unclassified WebAppsWG DOM unspecified PC All RESOLVED FIXED P2 normal --- 1 annevk annevk ayg bzbarsky eoconnor erik.arvidsson jonas mike Ms2ger shadow2531 www-dom public-webapps-bugzilla oldest_to_newest 51811 0 annevk 2011-07-30 14:16:35 +0000 Presto/WebKit/Trident support this Trident invention. It covers a subset of compareDocumentPosition() with a simpler API. 51863 1 ayg 2011-07-31 14:18:39 +0000 +1 from me in favor of contains() being defined on Node and working on all Nodes. Some kind of before()/after() would also be cool, and a way to retrieve the furthest ancestor of a Node so you can check if two Nodes are in the same tree. compareDocumentPosition() is the kind of incredible evil you get when JS APIs are made up by C++ programmers, and needs to be burned with fire. 51908 2 jonas 2011-08-01 17:11:37 +0000 Based on the use cases listed, it sounds like an API like: interface Node { ... Node getCommonAncestor(in Node other); ... }; might be a good solution. It would let you check if two nodes are in the same subtree by doing: if (node1.getCommonAncestor(node2)) { // In same subtree } and check for contains() by doing: if (node1.getCommonAncestor(node2) == node1) { // node1 contains node2 } Of course, performance would be better with separate .contains() and .inSameSubtree() functions. 51913 3 ayg 2011-08-01 18:31:08 +0000 contains() already exists, so it seems better to pave the cowpaths. getCommonAncestor() as you define it isn't well-named, because the result might not be an ancestor at all: it might be equal to one or both of the nodes. The Range interface already has a member called commonAncestorContainer, in fact, and the DOM Range spec uses the term "ancestor container of" to mean "the same as or ancestor of". Also, I'm not sure how intuitive it is to ask authors to use getCommonAncestor(). It seems better to have a few simple orthogonal tools than to have one general tool that you can use for several purposes -- the latter is half the problem with compareDocumentPosition() to start with. Asking authors to do node.getCommonAncestor(node) to get the furthest ancestor of a node or node1.getCommonAncestor(node2) == node 1 check for containment is roundabout. 56044 4 erik.arvidsson 2011-08-30 16:30:28 +0000 Moving contains to Node seems like a no brainer to me. 56158 5 annevk 2011-09-01 08:36:27 +0000 https://bitbucket.org/ms2ger/dom-core/changeset/9b02836d073d 56204 6 ayg 2011-09-01 22:39:36 +0000 For those interested, Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=683852 56465 7 bzbarsky 2011-09-07 13:32:13 +0000 The spec doesn't match Trident/WebKit/Presto for the case of |node.contains(node)|: per spec this returns false, but Trident/WebKit/Presto return true. Is this difference purposeful? The Gecko implementation seems to be following the spec at the moment. Really wish we wrote tests as we spec stuff. :( 56471 8 annevk 2011-09-07 14:28:52 +0000 https://bitbucket.org/ms2ger/dom-core/changeset/fa4879cb584d (Still need to write tests :-()