This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The behavior depends on whether the textnode has parent or not. If there is parent, boundary point's node can be changed, but if not, range is possibly just collapsed to the end of the original text node. I would expect that if the range is fully after the split point, the range's node would be updated. Also, it should be specified clearly what should happen in the case when textnode doesn't have parent and splittext happens between the range's boundary points. In this case the end point should probably point to the end of the original (modified) node.
If the range is fully... what?
If range start and end points are after the split point.
(In reply to comment #0) > The behavior depends on whether the textnode has parent or not. > If there is parent, boundary point's node can be changed, > but if not, range is possibly just collapsed to the end of the > original text node. > > I would expect that if the range is fully after the split point, the > range's node would be updated. This is what the spec used to say, but I changed it because it seemed like pointless extra complexity: https://bitbucket.org/ms2ger/dom-range/changeset/c622a27735ff Since you seem to feel strongly, we can just revert that change. I have no objections. > Also, it should be specified clearly what should happen in the case when > textnode doesn't have parent and splittext happens between the range's > boundary points. In this case the end point should probably point to the > end of the original (modified) node. That's what the spec said before I changed it, yeah. The four special cases for oldNode.splitText(offset) were (before I changed it): * new node's parent is null, range's start offset is >= offset, range's end offset is > offset: set range's start/end nodes to new node, decrement range's start/end offsets by offset * new node's parent is null, range's end node is old node, range's end offset is > offset: set range's end offset to offset (not sure why this needs a special case, though) * new node's parent is not null, range's start offset > offset: set range's start node to new node and decrement its start offset by offset * new node's parent is not null, range's end offset > offset: set range's end node to new node and decrement its end offset by offset
(In reply to comment #3) > Since you seem to feel strongly, we can just revert that change. I have no > objections. I don't feel really strongly either way, but the spec must be easy to read. Currently it is too difficult to figure out what should happen when text node doesn't have parent. And consistency, when possible, would be good. > * new node's parent is null, range's start offset is >= offset, range's end > offset is > offset: set range's start/end nodes to new node, decrement range's > start/end offsets by offset > * new node's parent is null, range's end node is old node, range's end offset > is > offset: set range's end offset to offset (not sure why this needs a > special case, though) Looks ok to me.
https://bitbucket.org/ms2ger/dom-core/changeset/f99128922c3d http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-text-split Thanks guys!
I changed it slightly to be more Gecko and test suite compatible. http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-text-split https://bitbucket.org/ms2ger/dom-core/changeset/c2f6b94c2352 In particular if there is no parent node the range will never be transfered to the new node.