RESOLVED FIXED 123565
Expose DOM4 ParentNode API on Document, Element, and DocumentFragment
https://bugs.webkit.org/show_bug.cgi?id=123565
Summary Expose DOM4 ParentNode API on Document, Element, and DocumentFragment
Anne van Kesteren
Reported 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
Attachments
Geoffrey Garen
Comment 1 2013-11-01 13:38:24 PDT
Are we really calling this thing ParentNode? That is a terrible name.
Ryosuke Niwa
Comment 2 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.
Ryosuke Niwa
Comment 3 2013-11-01 13:45:05 PDT
Oops, editors closed the bug :( Oh well, we'll never use DOM4 naming then.
Theresa O'Connor
Comment 4 2014-02-05 10:10:05 PST
Note that Gecko exposes .children etc. on DocumentFragment.
Radar WebKit Bug Importer
Comment 5 2014-02-05 10:11:07 PST
Ryosuke Niwa
Comment 6 2016-04-11 01:13:19 PDT
Chris, didn't you do this already?
Chris Dumez
Comment 7 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.
Note You need to log in before you can comment on or make changes to this bug.