Re: Consensus on the gray areas of the DOM API

Joe,

>Did we really agree that hasChildNodes should return false if there is a
>child but it is an empy-string Text node? If so, I missed it, since I read
>this as "If you ask whether there are children, you find out whether there
>are children. To find out if they're empty, ask for the string value of the
>attribute... or ask the kids for their contents."


Hmm.  If I remember our conversation on this subject, you were against
having Attr.getChildNodes().getLength() being >= 1.  From this, I deduced
that attributes with empty string value have no children.  If this is not
what you had in mind, what do you think Attr.hasChildNodes return when it
has empty string value?


>Ditto re getChildNodes. Returned NodeList should be empty if there are no
>nodes to list; it should not be empty if there is a node but it contains an
>empty string.


PR3 of the DOM SDK always returns true for hasChildNodes and always had at
least one child node.  This lead to some very unnatural looking code so I
changed things around in PR3A.  Note that I was not referring to empty Text
nodes being inserted with intentionally.  The user has references to
user-created text nodes so it wouldn't be right to wipe them out just
because they contain empty-string values.  I do agree that the description
is sloppy.

>(The question of whether an empty string text-node _should_ be created can
>be debated. But since I don't think the DOM provides any way to prevent
>this from happening, the important thing seems to be to return useful
>information when it does.)


>BTW, the last point of the latter is an incomplete sentence, and I'm not
>sure what was intended...


It was a phone call interruption <g>.

I think I'll prepend "Unofficial and Entirely Disagreeable" to the title
inside <blink> tags.

Best,

Don Park
Docuverse

Received on Monday, 12 October 1998 16:03:36 UTC