Re: [dom] mutation observer follow up

On Fri, Feb 17, 2012 at 10:51 AM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote:

> On 02/17/2012 08:41 PM, Adam Klein wrote:
>>
>> Yes, that's a major thing that's missing. In discussion with Rafael,
>> we've been thinking about trying to simplify the way textContent and
>> innerHTML records work such that the removals and insertions would be
>> in different records (in WebKit, at least, this would simplify
>> implementation). The basic idea would be that "remove all children"
>> would trigger one record, and then inserting the children would
>> trigger a second.  I'm interested if Olli has any input on this from
>> an implementation perspective in Firefox.
>>
>
>
> That feels a bit strange. Either we collect the changes to one
> record (both removals and insertions) or we create separate
> record for all the changes (one record for each node removal etc.)
> The latter would be easier for implementation, but would lead to
> tons of records.
> So, at least atm I'd prefer having just one record for
> textContent/innerHTML -like mutations


But we can't do that for some DOM APIs like Range.deleteContents or even
with textContent if we have mutation event listeners that synchronously
mutate DOM. So I'm not convinced that this is worthwhile.

- Ryosuke