Re: why does <text/> have no firstChild with value ""

Hi, Jonathan-

Jonathan Chetwynd wrote (on 10/3/10 11:16 AM):
> why does <text/> have no firstChild with value ""
>
> Can someone please point me to an explanation why the authors inclusion
> of an empty text element does not generate a firstChild with value the
> empty string?

The DOM is simply a memory representation of the tree structure of the 
document.  Since a self-closing (empty) element (whether <text/> or any 
other element), by definition, doesn't have any children, the DOM 
doesn't have a firstChild.  I understand why you find it inconvenient, 
but it's perfectly consistent and logical.  This is not something we can 
change, because it would risk breaking existing content, and it would be 
confusingly inconsistent for many people.

Here are some examples:
<foo/>                   <--  no children, so no firstChild
<foo></foo>              <--  no children, so no firstChild (this one 
tripped me up in the past)
<foo> </foo>             <--  one child, so firstChild is the "character 
data" (string) node " "
<foo><bar/></foo>        <--  one child, so firstChild is the <bar/> element
<foo> <bar/></foo>       <--  two children, so firstChild is the 
"character data" (string) node " "
<foo><bar/> <cow/></foo> <--  two children, so firstChild is the <bar/> 
element

Each discrete "token" is a node; so, elements, blank spaces and 
newlines, comments... each of these represents a "node" (or branch) of 
the tree (even attributes are nodes, but are not considered children of 
an element... they are more like leaves than branches).  Every branch is 
attached to one and only one "parent branch" (except the root node), and 
each branch may or may not have one or more (so, 0 or more) branches 
coming off it.

If there is no token in the document that's considered a branch, the 
tree won't add branches that aren't there.  That would wreak havoc with 
scripts that are trying to accurately iterate through the number of 
children of an element, for example... 1 child could mean either 0 or 1 
child... and what would happen if you tried to move or clone this 
phantom child?


> my issue is that the current methodology requires additional coding and
> complication for the author, and little or no benefit to the UA, afaict.

No, you simply have to adjust your thinking about what firstChild and 
nodeValue means, and use the convenience methods that are available to 
work around the (logical) quirks in that model.

Jeff correctly pointed out the .textContent property, which is even more 
convenient than .firstChild.nodeValue, and it does what you want:

    var foo = document.getElementById('foo');
    foo.textContent = 'foooooo';

or

    var foo = document.createElementNS("http://www.w3.org/2000/svg", 
"text");
    foo.textContent = "foooooo";
    document.documentElement.appendChild( foo );


So, armed with that knowledge, I hope you can agree that the document 
object model is necessarily consistent, and that element.textContent is 
the correct and most convenient way to accomplish the particular task 
you're doing.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Sunday, 3 October 2010 16:30:44 UTC