WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Add attachment
proposed patch, testcase, etc.
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
<
rdar://problem/15991023
>
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.
Top of Page
Format For Printing
XML
Clone This Bug