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 | ||
Anne van Kesteren
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
Are we really calling this thing ParentNode? That is a terrible name.
Ryosuke Niwa
(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
Oops, editors closed the bug :(
Oh well, we'll never use DOM4 naming then.
Theresa O'Connor
Note that Gecko exposes .children etc. on DocumentFragment.
Radar WebKit Bug Importer
<rdar://problem/15991023>
Ryosuke Niwa
Chris, didn't you do this already?
Chris Dumez
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.