23694 2013-10-31 22:27:05 +0000 Should element.getElementById() consider the element itself when searching 2013-11-03 23:48:27 +0000 1 1 1 Unclassified WebAppsWG DOM unspecified PC Linux RESOLVED INVALID P2 normal --- 1 bugs annevk bzbarsky glenn mike www-dom public-webapps-bugzilla oldest_to_newest 95640 0 bugs 2013-10-31 22:27:05 +0000 It is odd if getElementById can't be used reliably in a disconnected subtree to find element by id. Based on testing querySelector seems to have similar oddity, but we don't need to copy its behavior here, IMO. 95647 1 bzbarsky 2013-11-01 00:08:20 +0000 SVGSVGElement.getElementById does _not_ consider the element itself. Do we really want to break compat there? 95648 2 bzbarsky 2013-11-01 00:08:49 +0000 A possibility is to add an optional boolean argument, defaulting false, for whether to include the root, I guess... 95671 3 annevk 2013-11-01 11:49:12 +0000 None of the getElement* methods behave this way. Ask web developers, they'll expect it to search among the descendants, not inclusive descendants. 95673 4 bugs 2013-11-01 11:57:46 +0000 http://www.w3.org/TR/SVG/struct.html#__svg__SVGSVGElement__getElementById is vague, but implementations indeed don't include the root element of a subtree. So, I guess we need to live with that oddity, and perhaps add the boolean param later if needed. 95744 5 glenn 2013-11-03 23:48:27 +0000 We only "expect" it to because we've been bit by it and learned its weird behavior. That doesn't mean it's how we *want* it to behave. This can't be changed now, of course, but I definitely recall being annoyed at querySelector not matching the top element, and having to manually matchSelector it separately. I don't know if it's worth adding a parameter, though (if so, it should be a dictionary parameter and not a bare boolean). (If we add a function to search up the tree, eg. "find the nearest container that matches a selector", it absolutely needs to check the initial node, though.)