I think it keeps the design simple. A node may exist in isolation but the more interesting case is the DOM tree. With removeChild
, the node to be removed must be a child of the node on which the method was called.
Getting a list of all children and doing a manual comparison against each is not that expensive an operation. However, searching all descendants for a node that is to be removed is indeed expensive.
Edit: In response to your update, a browser is simply implementing the DOM spec, which defines a removeChild
method on Node
. The spec, in my opinion, has to be unambiguous and free of assumptions. It is similar to Dependency Injection from that perspective. The DOM Core spec models a tree using building blocks such as Node, Element, etc. Adding a lone method such as removeNode
somewhere in these building blocks means the method has implicit knowledge about its environment - that it may
be a child of some node, and it should be removed from there if it is.
The task of w3 is to make a very robust API which makes most things possible. They shouldn't worry about syntactic sugar as that can always be written around the native APIs if they are well written.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…