[Bug 13164] New: Centralize changes to CharacterData so other specs can hook in easily

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

           Summary: Centralize changes to CharacterData so other specs can
                    hook in easily
           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


Bug 13153 is related.  If this is fixed, that becomes invalid.

There are at least two things that currently care about when CharacterData
changes: range mutations and mutation events.  Currently CharacterData is
changed directly by lots of different parts of the spec.  This leads to ugly
stuff like

"""
This includes (but is not limited to) if a script or specification sets a data
or nodeValue or textContent attribute, or if a script or specification calls
the replaceWholeText() method, or if a specification says to set the node's
data without specifically referring to its data attribute.
"""
http://html5.org/specs/dom-range.html#range-behavior-under-document-mutation

This could be simplified a bunch if all CharacterData changes were funneled
through one algorithm.  It could be replaceData().  Thus you'd change
deleteData(offset, count) to work the same as replaceData(offset, count, 0),
and insertData(offset, data) to work the same as replaceData(offset, 0, data),
and text.data = s to work the same as replaceData(0, -1, s), and so on.  This
is probably how implementations work anyway (I've been told it's how Gecko
works).  You might then add an explicit hook for other specs to use, as the
last step of the algorithm, like "Run <span>CharacterData change steps</span>"
or something, with "CharacterData change steps" defined as "whatever other
specs say".

If you do this, one thing to keep in mind is what to do about no-ops.  If the
new data winds up being the same as the old data, how is it treated?  WebKit
doesn't mutate ranges in this case, and that's the behavior I specced. 
Presumably if we do that, we don't want to fire mutation events (or their
replacements) either.  So you could add a step to the effect of "if this isn't
going to actually change anything, abort" somewhere before the hook that other
specs use.

-- 
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 Wednesday, 6 July 2011 20:30:16 UTC