This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 16409 - DOM4: Consider LeafNode interface which Node inherits from
Summary: DOM4: Consider LeafNode interface which Node inherits from
Status: RESOLVED WONTFIX
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: DOM (show other bugs)
Version: unspecified
Hardware: All All
: P2 enhancement
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-16 20:54 UTC by Alex Vincent
Modified: 2012-05-15 10:53 UTC (History)
3 users (show)

See Also:


Attachments

Description Alex Vincent 2012-03-16 20:54:00 UTC
Andreas Gal's domjs project ( https://github.com/andreasgal/dom.js ) has an interesting idea:  a separate class for "leaf nodes", which cannot have children.

I wonder if this might be worth adding to the DOM4 spec, by splitting the Node interface into two parts:  
(1) A LeafNode interface which implements all the current Node's interface properties except firstChild, childNodes, lastChild, insertBefore, appendChild, replaceChild, and removeChild.
(2) A Node interface which inherits from LeafNode and adds those extracted properties.

interface LeafNode : EventTarget;
interface Node : LeafNode;

It might make text nodes, comments, etc. - nodes that can't have children - somewhat simpler.

I'm only asking for consideration of the idea.
Comment 1 Boris Zbarsky 2012-03-16 21:18:54 UTC
Wouldn't this break existing scripts that iterate over the DOM?  How do you expect UAs to implement it?
Comment 2 Anne 2012-03-19 16:04:23 UTC
We have followed this approach for new mutation methods. Not sure if we can do it for the legacy ones.
Comment 3 Anne 2012-03-19 16:05:06 UTC
If you want to do this I suggest experimenting in a browser whether you can move some methods down from Node and then remove them from selected interfaces.
Comment 4 Anne 2012-05-15 10:53:55 UTC
Resolving as WONTFIX because changing the classes around is a huge compatibility risk. If a browser (like with the Attr redesign) is willing to test this out we'll look at this more concretely.