Re: Mutation events replacement

On Thu, Jul 7, 2011 at 3:19 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Thu, Jul 7, 2011 at 2:32 PM, Rafael Weinstein <rafaelw@google.com> wrote:
>> On Thu, Jul 7, 2011 at 1:58 PM, Ryosuke Niwa <rniwa@webkit.org> wrote:
>>> On Thu, Jul 7, 2011 at 12:18 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>>>
>>>> I don't think John J Barton's proposal to fire "before mutation
>>>> notifications" is doable.
>>>
>>> I concur.  Being synchronous was one of the reasons why the existing DOM
>>> mutation events don't work.  We shouldn't adding yet-another synchronous
>>> event here.
>>>>
>>>> In short before spending more time on this, I'd like to see a
>>>> comprehensive proposal, including a description of the use cases it
>>>> solves and how it solves them. I strongly doubt that this approach is
>>>> practical.
>>>
>>> Totally agreed.
>>>>
>>>> I really like Rafael's proposal to pass a list of mutations that has
>>>> happened to the notification callbacks. This has the advantage that
>>>> scripts get *all* the changes that has happened at once, making it
>>>> possible to make decisions based on all changes made, rather than
>>>> piece-wise getting the information in separate callbacks. It also has
>>>> the advantage that we can provide much more detailed information
>>>> without having to make multiple calls from C++ to JS which is good for
>>>> performance. For example it seems very doable to provide lists of all
>>>> nodes that has been removed and added while still keeping performance
>>>> reasonable.
>>>
>>> Enthusiastically agreed.
>>>>
>>>> I'll write up a proposal based on this idea. Others should feel free
>>>> to beat me to it :)
>>>
>>> Nice!  Looking forward to it.
>>>>
>>>> The main concern that I have with this proposal is that it's so
>>>> different from mutation events that it might not satisfy the same use
>>>> cases. Consider a widget implementation that currently observes the
>>>> DOM using mutation events and makes it possible to write code like:
>>>>
>>>> myWidgetBackedElement.appendChild(someNode);
>>>> myWidgetBackedElement.someFunction();
>>>>
>>>> where someFunction depends on state which is updated by the mutation
>>>> event handler. Such a widget implementation is simply not doable with
>>>> these semi-asynchronous callbacks.
>>>
>>> Right.  But on the other hand, if this code were to run inside a mutation
>>> observer, it won't work in your proposal either.  So the questions is
>>> whether writing a function that depends on state updated by the mutation
>>> observer without a mutation observer, and then later calling it inside a
>>> mutation observer happens frequently enough to annoy developers or not.
>>>>
>>>> On the other hand, maybe this isn't a big deal. We are definitely
>>>> short on use cases for mutation events in general which is a problem.
>>
>> Right. Olli & Jonas, I'd really like to understand your thinking about this.
>>
>> Are we not understanding something about your proposal?
>>
>> If accommodating the above is a goal, it seems like the only option is
>> to have mutation events be fully synchronous. I.e. It doesn't seem
>> acceptable to encourage a widget author to expose an API that depends
>> on never being called inside a mutation callback and/or prevents it
>> from being used as a building block for a higher-level abstraction.
>
> It's definitely the case that APIs will behave differently inside the
> mutation notification, and that the code example showed above would
> not work from inside the notification.
>
> Basically I'm asking people to tread carefully inside mutation
> notifications and only do the minimal amount of data gathering.

Heh. We're kind of in violent agreement here. =-)

>
> So yes, my proposal only solves the usecase outside mutation handlers.
> However this is arguably better than never solving the use case as in
> your proposal. I'm sure people will end up writing buggy code, but
> ideally this will be found and fixed fairly easily as the behavior is
> consistent. We are at least giving people the tools needed to
> implement the synchronous behavior.

Ok. Thanks for clarifying. It's helpful to understand this.

I'm glad there's mostly common ground on the larger issue. The point
of contention is clearly whether accommodating some form of sync
mutation actions is a goal or non-goal.

It occurs to me that the main use case raised in favor of sync
mutation actions is more or less the custom component/widget use case.
This seems to border alot on XBL2. Maybe it's useful to look at it
through that lens?

/me grabs blindly at the air for good ideas about how to come to consensus.

>
> / Jonas
>

Received on Friday, 8 July 2011 00:23:58 UTC