[Bug 13250] New: In "replace data", bail out early if the data will be the same

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13250

           Summary: In "replace data", bail out early if the data will be
                    the same
           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


Before the step "Insert data into data after offset code units.", add something
like

  # Substring data with offset offset and count count, and let current data be
the result.
  # If current data equals data, terminate these steps.

That way, if there's no actual change, mutation events won't fire and ranges
won't be affected.  E.g., if you have a selection in a text node like
foo[bar]baz, and you do text.data = text.data, we want the selection to remain
foo[bar]baz and not become []foobarbaz.

Among browsers I tested a few months ago, Chrome does this special-casing, and
it makes sense.  That way text.data = text.data is a no-op, which is what you'd
expect.  Authors are likely to do things like

  function getNewData(data) {
    if (flibberty()) {
      data += "!";
    }
    if (squizzle()) {
      data = data.replace(/elephant/g, "cantaloupe");
    }
    return data;
  }
  text.data = getNewData(text.data);

and will naturally expect that nothing will happen if flibberty() and
squizzle() are both false.  Of course, if they're really worried about range
mutations they should be passing the actual text node and using
appendData/replaceData to make the changes, but we can at least make it easy
for them to get it right in as many cases as possible.

-- 
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 Thursday, 14 July 2011 15:25:15 UTC