Bug 123565

Summary:	Expose DOM4 ParentNode API on Document, Element, and DocumentFragment
Product:	WebKit	Reporter:	Anne van Kesteren <annevk>
Component:	DOM	Assignee:	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.