<p>I got embroiled in a discussion about DOM implementation quirks yesterday, with gave rise to an interesting question regarding Text.splitText and Element.normalise behaviours, and how they should behave.</p>

<p>In <a href="http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-one-core.html" rel="nofollow noreferrer">DOM Level 1 Core</a>, Text.splitText is defined as...</p>

<blockquote>
  <p>Breaks this Text node into two Text nodes at the specified offset, keeping both in the tree as siblings. This node then only contains all the content up to the offset point. And a new Text node, which is inserted as the next sibling of this node, contains all the content at and after the offset point.</p>
</blockquote>

<p>Normalise is...</p>

<blockquote>
  <p>Puts all Text nodes in the full depth of the sub-tree underneath this Element into a "normal" form where only markup (e.g., tags, comments, processing instructions, CDATA sections, and entity references) separates Text nodes, i.e., there are no adjacent Text nodes. This can be used to ensure that the DOM view of a document is the same as if it were saved and re-loaded, and is useful when operations (such as XPointer lookups) that depend on a particular document tree structure are to be used.</p>
</blockquote>

<p>So, if I take a text node containing "Hello World", referenced in textNode, and do</p>

<pre><code>textNode.splitText(3)
</code></pre>

<p>textNode now has the content "Hello", and a new sibling containing " World"</p>

<p>If I then</p>

<pre><code>textNode.parent.normalize()
</code></pre>

<p><em>what is textNode</em>? The specification doesn't make it clear that textNode has to still be a child of it's previous parent, just updated to contain all adjacent text nodes (which are then removed). It seems to be to be a conforment behaviour to remove all the adjacent text nodes, and then recreate a new node with the concatenation of the values, leaving textNode pointing to something that is no longer part of the tree. Or, we can update textNode in the same fashion as in splitText, so it retains it's tree position, and gets a new value.</p>

<p>The choice of behaviour is really quite different, and I can't find a clarification on which is correct, or if this is simply an oversight in the specification (it doesn't seem to be clarified in levels 2 or 3). Can any DOM/XML gurus out there shed some light?</p>

[{'answer_id': 34202, 'author': 'Sam Brightman', 'author_id': 2492, 'author_profile': 'https://Stackoverflow.com/users/2492', 'pm_score': 2, 'selected': False, 'text': "<p>While it would seem like a reasonable assumption, I agree that it is not explicityly made clear in the specification. All I can add is that the way I read it, one of either <code>textNode</code> or it's new sibling (i.e. return value from <code>splitText</code>) would contain the new joined value - the statement specifies that all nodes <em>in the sub-tree</em> are put in normal form, not that the sub-tree is normalised to a new structure. I guess the only safe thing is to keep a reference to the parent before normalising.</p>\n"}, {'answer_id': 45831, 'author': 'Adrian Mouat', 'author_id': 4332, 'author_profile': 'https://Stackoverflow.com/users/4332', 'pm_score': 2, 'selected': False, 'text': "<p>I think all bets are off here; I certainly wouldn't depend on any given behaviour. The only safe thing to do is to get the node from its parent again.</p>\n"}, {'answer_id': 45869, 'author': 'David Singer', 'author_id': 4618, 'author_profile': 'https://Stackoverflow.com/users/4618', 'pm_score': 4, 'selected': True, 'text': "<p>I was on the DOM Working Group in the early days; I'm sure we <em>meant</em> for textNode to contain the new joined value, but if we didn't <em>say</em> it in the spec, it's possible that <em>some</em> implementation <em>might</em> create a new node instead of reusing textNode, though that would require more work for the implementors.</p>\n\n<p>When in doubt, program defensively.</p>\n"}]
['https://Stackoverflow.com/questions/30049', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/1200/']