W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2011

[whatwg] DOM Range: redefining behavior under DOM mutation

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 29 Mar 2011 14:43:24 -0400
Message-ID: <4D92284C.2050508@mit.edu>
On 3/29/11 2:37 PM, Boris Zbarsky wrote:
>> That already has to happen for
>> insertData()/deleteData()/appendData(), right? All browsers treat
>> those differently from just setting the data to the equivalent
>> string.
> Those map directly to atomic operations on CharacterData, for what it's
> worth.

Oh, I see; I had misunderstood what you were saying, so didn't quite 
answer your question.

The point is, these operations are atomic, so there is no DOM-visible 
intermediate state.  In Gecko's case, there is an internal 
CharacterDataChanged notification, which is passed the following 

1)  Position of change start in the CharacterData node's text.
2)  Length of removed text starting at that position (can be 0).
3)  Length of inserted text starting at that position (can be 0).

Given all three pieces of information, it's easy to adjust the range 
endpoints in a "sensible" way.

Note that technically that behavior is a violation of DOM2 Range, but 
that's what we're trying to replace, right?

Received on Tuesday, 29 March 2011 11:43:24 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:31 UTC