123565 2013-10-31 04:40:22 -0700 Expose DOM4 ParentNode API on Document, Element, and DocumentFragment 2016-04-11 08:16:18 -0700 1 1 1 Unclassified WebKit DOM 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED InRadar, WebExposed P2 Normal --- 1 annevk webkit-unassigned ap barraclough benjamin cdumez eoconnor ggaren kling koivisto rniwa syoichi webkit-bug-importer oldest_to_newest 945486 0 annevk 2013-10-31 04:40:22 -0700 And remove SVGSVGElement.prototype.getElementById while you're at it, if you have that. See: http://dom.spec.whatwg.org/#parentnode 945998 1 ggaren 2013-11-01 13:38:24 -0700 Are we really calling this thing ParentNode? That is a terrible name. 946000 2 rniwa 2013-11-01 13:39:34 -0700 (In reply to comment #1) > Are we really calling this thing ParentNode? That is a terrible name. Indeed! I've filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23698 to that end. 946005 3 rniwa 2013-11-01 13:45:05 -0700 Oops, editors closed the bug :( Oh well, we'll never use DOM4 naming then. 976792 4 eoconnor 2014-02-05 10:10:05 -0800 Note that Gecko exposes .children etc. on DocumentFragment. 976795 5 webkit-bug-importer 2014-02-05 10:11:07 -0800 <rdar://problem/15991023> 1182629 6 rniwa 2016-04-11 01:13:19 -0700 Chris, didn't you do this already? 1182700 7 cdumez 2016-04-11 08:16:18 -0700 I have just compared our implementation with the specification and it does appear that: - Our ParentNode.idl matches the DOM spec at https://dom.spec.whatwg.org/#parentnode - Document, DocumentFragment and Element implement ParentNode So I think we can close this bug. Also not that actual naming we use does not matter that much since the 'ParentNode' naming is not web-exposed. That said, there are advantages to matching the naming in the spec.