W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2012

Re: [dom] mutation observer follow up

From: Ryosuke Niwa <rniwa@webkit.org>
Date: Fri, 17 Feb 2012 11:36:01 -0800
Message-ID: <CABNRm62u+T1bomfYvW5G0TCTT5QeX3dfWbV1wDTtqC7R6xk7Tg@mail.gmail.com>
To: olli@pettay.fi
Cc: Adam Klein <adamk@chromium.org>, Anne van Kesteren <annevk@opera.com>, "www-dom@w3.org" <www-dom@w3.org>
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
Received on Friday, 17 February 2012 19:36:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:18 UTC