W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: DOM Mutation Events Replacement: Findings from implementing "net-effect" projections

From: Ryosuke Niwa <rniwa@webkit.org>
Date: Mon, 22 Aug 2011 13:44:24 -0700
Message-ID: <CABNRm63_GdcQt0s+iGFn4dMT_XQ2ezQb-VVk=TG86gW6jw493Q@mail.gmail.com>
To: olli@pettay.fi
Cc: Rafael Weinstein <rafaelw@google.com>, Webapps WG <public-webapps@w3.org>, Dave Raggett <dsr@w3.org>
On Wed, Aug 17, 2011 at 3:17 AM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote:

> On 08/17/2011 04:54 AM, Rafael Weinstein wrote:
>
>> TL;DR;
>>
>> 1) ObserveSubtree semantics doesn't provide a robust mechanism for
>> observing a tree/fragment, and if we don't provide something more
>> complete, libraries will likely register observers at every node in
>> the document.
>>
>
> ModificationBatch approach should provide as much information as
> current mutation events.


No, the problem is that the list of mutations is given asynchronously in
some cases.

Say you have the following DOM tree:
body
    div
        span class="special"
            #text('hello')

and div is removed.  At this point, the list of mutations we have is:
(ChildlistChanged, body, div)
where div has the subtree:
span class="special"
    #text('hello')

If observers (e.g. of widget library) wanted to detect whether any span with
the "special" classname has been removed from the document, it can do so
when it receives this list of mutations in this case.

But now suppose that another observer of this mutation list decides to
remove span from div's child list before my observer sees the list of
mutations.  Oops!  I don't have any idea whether span was removed or not
because all I get to see is (ChildlistChanged, body, div) and div doesn't
have any children.

Sure, this issue is prevalent in the existing mutation events but it's a
good use case to address.  In fact, providing a way to work-around this
issue (by providing means to watch all nodes with the same owner document)
might provide a strong incentive for authors to start using our new API.

But is that a common enough case which the API needs to handle.
> I would think that a script library which wants to handle such case,
> can just use the API to observe "everything".
>

Recall the distributed editing use cases pointed by Dave Raggett for
example:
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0416.html
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0381.html

- Ryosuke
Received on Monday, 22 August 2011 20:51:41 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT