This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We already special-case splitText(). normalize() should be special-cased too. See Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=191864
Just to remind, for some reason normalize() is removed from http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-core atm (I think normalize() is useful, and if splitText() has special case in range spec, so should normalize() have. Personally I think neither of them should be special cased, but I don't care too much)
Hmm, that's weird. normalize() is useful, I've used it. It should be re-added. (This might explain why I didn't special-case it, because I didn't see it in the spec.)
Filed bug 13868.
Is this done by virtue of reusing other algorithms? http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-node-normalize
Test-case: data:text/html,<!DOCTYPE html> <script> var range = document.createRange(); document.head.appendChild(document.createTextNode("abc")); range.setStart(document.head.lastChild, 2); document.head.appendChild(document.createTextNode("def")); range.setEnd(document.head.lastChild, 2); document.head.normalize(); alert(range.startContainer + "," + range.startOffset + "," + range.endContainer + "," + range.endOffset); </script> Chrome 17 dev and Firefox 12.0a1 both alert "[object Text],2,[object Text],5" (so ab[cde]f stays selected). Opera Next 12.00 alpha gives "[object Text],2,[object HTMLHeadElement],2" (changing selection to ab[cdef}). I don't have IE to test. The spec requires "[object Text],2,[object Text],6", as far as I read it (changing selection to ab[cdef]). Basically, unless Gecko and WebKit are both willing to drop their special-case behavior, we should add similar behavior to the spec.
IE9 gives "[object HTMLHeadElement],1,[object Text],3".
In that case, I still say we go with Gecko/WebKit, since it's the most interoperable right now. The spec doesn't match anyone. The spec should probably go something like this: """ For each Text node descendant of the context object: 1. Let node be the Text node descendant. 2. Let previous sibling be node's previous sibling. 3. If previous sibling is not a Text node, continue with the next Text node descendant of the context object. 4. Let length be previous sibling's length attribute value. 4. Replace data with node previous sibling, offset length, count 0, and data node's data. 5. For each boundary point whose node is node, increase its offset by length and set its node to previous sibling. 6. Remove node. """ Does that sound good? If so, I'll write some tests and make the change.
If you have three Text-nodes the operation described does not seem ideal. Also, for mutation observers, do we want a single MutationRecord for each set of contiguous Text nodes affected? Because that would not work either with this description.
Well, you need one MutationRecord for each CharacterData change anyway, but yes, we could get away with fewer childList changes than my text allows. Although we'd have to define "remove" for multiple nodes at a time. How about: """ For each Text node descendant of the context object: 1. Let node be the Text node descendant. 2. Let length be node's length attribute value. 3. Let data be the concatenation of the data of node's contiguous Text nodes (excluding itself), in tree order. 4. Replace data with node node, offset length, count 0, and data data. 5. Let current node be node's next sibling. 6. While current node is a Text node: 1. For each boundary point whose node is current node, add length to its offset and set its node to node. 2. Add current node's length attribute value to length. 3. Set current node to its next sibling. 7. Remove node's contiguous Text nodes (excluding itself), in tree order. """
My point was that you'd only need one "characterData" MutationRecord for three consecutive Text nodes. The comment 9 algorithm also replaces when there's no need. Other than that I suppose it's okay. (Until we add mutation observers.)
Aryeh, can you have another look at this now we have mutation observers? I don't think there's a need to optimize removal anymore.
Is there anything wrong with the algorithm in comment 9 now, relative to the current spec's algorithm? If not, I'll change the spec.
So why do you need to manually update the boundary points? Does concept-node-remove not take care of that? Also currently the other text updating Ranges does not use the boundary points terminology. Still not quite sure whether it should.
(In reply to comment #13) > So why do you need to manually update the boundary points? Does > concept-node-remove not take care of that? That will collapse the boundary point to the end of the node. See comment 5 -- the selected text should remain "ab[cde]f", but per spec it would become "ab[cdef]". > Also currently the other text updating Ranges does not use the boundary points > terminology. Still not quite sure whether it should. Okay, I can modify it for that.
https://bitbucket.org/ms2ger/dom-core/changeset/bd9c816a31da No tests for now, but I added a TODO to the mutation tests.