Bug 123565

Summary: Expose DOM4 ParentNode API on Document, Element, and DocumentFragment
Product: WebKit Reporter: Anne van Kesteren <annevk>
Component: DOMAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: ap, barraclough, benjamin, cdumez, eoconnor, ggaren, kling, koivisto, rniwa, syoichi, webkit-bug-importer
Priority: P2 Keywords: InRadar, WebExposed
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   

Description Anne van Kesteren 2013-10-31 04:40:22 PDT
And remove SVGSVGElement.prototype.getElementById while you're at it, if you have that.

See: http://dom.spec.whatwg.org/#parentnode
Comment 1 Geoffrey Garen 2013-11-01 13:38:24 PDT
Are we really calling this thing ParentNode? That is a terrible name.
Comment 2 Ryosuke Niwa 2013-11-01 13:39:34 PDT
(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.
Comment 3 Ryosuke Niwa 2013-11-01 13:45:05 PDT
Oops, editors closed the bug :(

Oh well, we'll never use DOM4 naming then.
Comment 4 Theresa O'Connor 2014-02-05 10:10:05 PST
Note that Gecko exposes .children etc. on DocumentFragment.
Comment 5 Radar WebKit Bug Importer 2014-02-05 10:11:07 PST
<rdar://problem/15991023>
Comment 6 Ryosuke Niwa 2016-04-11 01:13:19 PDT
Chris, didn't you do this already?
Comment 7 Chris Dumez 2016-04-11 08:16:18 PDT
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.