13164 2011-07-06 20:30:14 +0000 Centralize changes to CharacterData so other specs can hook in easily 2011-07-24 18:04:13 +0000 1 1 1 Unclassified WebAppsWG DOM unspecified All All RESOLVED FIXED P2 enhancement --- 13248 13250 1 ayg annevk jonas mike Ms2ger www-dom public-webapps-bugzilla oldest_to_newest 50748 0 ayg 2011-07-06 20:30:14 +0000 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. 50754 1 annevk 2011-07-06 21:12:04 +0000 Define common algorithm to define the methods in is one way to have less text in that section. Addressing this bug would involve having a single callback for other specifications, but that needs to wait for a solution to mutation events. 50759 2 ayg 2011-07-06 21:41:18 +0000 Even before mutation events are solved, it would be useful to have a single callback so that the description of range mutation can be simplified. DOM Range is currently pretty ugly on this subject, as you can see in the part of the spec I linked to in comment 0. 51004 3 annevk 2011-07-14 11:43:45 +0000 They now use a single algorithm. 51020 4 ayg 2011-07-14 14:45:00 +0000 Looks good to me, thanks!