Re: Why can't you set an element's value?

Gavin Stokes wrote:

> I'm trying to be patient and learn the reasoning behind some DOM 
> design decisions.  To that end, let me ask: Why does setNodeValue on 
> an Element do nothing?  Given that XML is all text, shouldn't every 
> element be able to contain text as its value?  What other kind of 
> value would it contain, anyway?  Why do we have to add a text node?

An element may contain other elements and text may be interspersed 
between the elements in an element.  This is found quite commonly in 
almost any HTML document.

> There is question after question on various DOM-implementation 
> discussion forums from people who are baffled by the fact that 
> setNodeValue does nothing, so I know this is a source of bewilderment 
> for many.

If the confusion is surrounding text nodes, then I am not sure what they 
would think should be an alternative.  Naked strings cannot live very 
well in a node hierarchy or as children of an element, because you have 
no way to get to the next sibling, for example.  This is true of any 
node that can have children.

The Attr node actually does allow you to call setNodeValue, but 
underneath it constructs a Text node to hold the content and wipes out 
existing children (or something equivalent).  This may be OK for Attr, 
because people who don't want to understand a node hierarchy can pretend 
that there are no children since getNodeValue can always give you 
something nearly functionally equivalent to what you would set, and 
there are a number of environments where the only child of an Attr is a 
single text node, since they are not worried about losing entity 
references, especially where the result is never written out or where a 
specification such as HTML has made additional general entity 
declarations illegal.

Elements were designed to have structural child elements intermixed with 
text.  If people expected setNodeValue to work, they would also expect 
getNodeValue to work, and it cannot give you anywhere close to the same 
thing, since the children cannot be present in a literal string value, 
and making it a parsed string value would make it quite unusable for 
many simple applications and would bind it to a single parser and 
serializer.

There have been attempts to do this sort of thing in certain browser 
APIs using names like "innerText" which strips out all the child tags 
(and hence is not symmetrical if you want to setInnerText) and 
"outerText" which puts them in, and makes assumptions about parsing or 
serialization and would require the caller to escape characters to make 
them literal, etc.  These would be quite complex to define well and 
would introduce backward depencencies from DOM Node attributes to the 
parser that the DOM has been free of up until now.

If you can think of a simpler way of abstracting the operation that 
didn't involve so much complexity, I it might be warmly recieved. 
 Naturally for a particular implementation to make a proprietary 
function that hard-codes to its parser/serializer and make assumptions 
the same way its own parser would handle things is easy, but you 
shouldn't expect it to be portable or part of the standard API 
specification which was designed to be portable between quite different 
environments.

Ray Whitmer
rayw@netscape.com

Received on Friday, 29 June 2001 13:21:20 UTC