W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2011

[Bug 13153] New: replaceData() should insert before deleting, to give better range mutation behavior

From: <bugzilla@jessica.w3.org>
Date: Tue, 05 Jul 2011 20:40:14 +0000
To: www-dom@w3.org
Message-ID: <bug-13153-4009@http.www.w3.org/Bugs/Public/>

           Summary: replaceData() should insert before deleting, to give
                    better range mutation behavior
           Product: WebAppsWG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DOM Core
        AssignedTo: annevk@opera.com
        ReportedBy: Simetrical+w3cbug@gmail.com
         QAContact: member-webapi-cvs@w3.org
                CC: mike@w3.org, www-dom@w3.org



This does replaceData(1, 1, "uu") on a text node "foo".  A range collapsed like
"fo[]o" then becomes "f[]uuo" per the current spec.  This is because first you
delete one character, so it becomes "f[]o", then you insert the new characters,
and insertions always go after a boundary point.  If you instead inserted them
before the substring to be deleted, then deleted the substring, it would first
be "fuuo[]o", then "fuu[]o".  Then the boundary point goes where it logically
belongs -- after the replacement for the thing it was already after.

The current spec matches the behavior of IE9, Firefox 6.0a2, and Chrome 14 dev
(they log "1" in the test).  Opera 11.50 matches my proposed behavior (logs
"3").  I don't think this would affect compat, so switching to Opera's behavior
should be safe.

To be clear, I'm asking that the spec be changed to say something like

"The replaceData(offset, count, data) method must act as if the insertData()
method is invoked with offset and data as arguments followed by the
deleteData() method with (offset + data.length) and count as arguments and
re-throw any exceptions these methods might have thrown."

AFAIK, this should only affect range mutations (for the better) and mutation
events (unlikely to make a compat difference, I hope).

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Tuesday, 5 July 2011 20:40:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:17 UTC