13843 2011-08-19 21:42:00 +0000 Define Range mutation for normalize() 2012-03-21 21:18:07 +0000 1 1 1 Unclassified WebAppsWG DOM unspecified All All RESOLVED FIXED P2 normal --- 13868 1 ayg annevk adamk annevk bugs jrossi mike public-webapps travil www-dom public-webapps-bugzilla oldest_to_newest 55511 0 ayg 2011-08-19 21:42:00 +0000 We already special-case splitText(). normalize() should be special-cased too. See Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=191864 55512 1 bugs 2011-08-19 21:57:07 +0000 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) 55514 2 ayg 2011-08-19 22:07:37 +0000 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.) 55595 3 ayg 2011-08-22 19:48:20 +0000 Filed bug 13868. 61837 4 annevk 2011-12-20 19:52:45 +0000 Is this done by virtue of reusing other algorithms? http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-node-normalize 62059 5 ayg 2011-12-27 20:14:43 +0000 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. 62091 6 annevk 2011-12-28 09:23:03 +0000 IE9 gives "[object HTMLHeadElement],1,[object Text],3". 62104 7 ayg 2011-12-28 16:41:43 +0000 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. 62105 8 annevk 2011-12-28 16:47:35 +0000 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. 62107 9 ayg 2011-12-28 17:24:47 +0000 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. """ 62108 10 annevk 2011-12-28 17:45:41 +0000 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.) 65894 11 annevk 2012-03-21 12:09:31 +0000 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. 65905 12 ayg 2012-03-21 19:16:16 +0000 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. 65907 13 annevk 2012-03-21 19:25:16 +0000 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. 65910 14 ayg 2012-03-21 19:51:02 +0000 (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. 65915 15 ayg 2012-03-21 21:18:07 +0000 https://bitbucket.org/ms2ger/dom-core/changeset/bd9c816a31da No tests for now, but I added a TODO to the mutation tests.