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

Re: Mutation events replacement

From: Ryosuke Niwa <rniwa@webkit.org>
Date: Sun, 3 Jul 2011 10:26:14 -0700
Message-ID: <CABNRm605pbhpZCCHbX99QcnMzVwAAABabnEgj3R2i_udyShptg@mail.gmail.com>
To: johnjbarton@johnjbarton.com
Cc: public-webapps@w3.org
On Sun, Jul 3, 2011 at 8:41 AM, John J. Barton
<johnjbarton@johnjbarton.com>wrote:

> On 7/2/2011 8:50 PM, Boris Zbarsky wrote:
>
>> On 7/2/11 1:46 PM, John J. Barton wrote:
>>
>>> 2) element transformation. The replacement fires "after" a mutation.
>>> Library or tools that want to transform the application dynamically want
>>> to get notification "before" the mutation. A common solution then is
>>> to bracket changes:
>>> "beforeChange" or "onModelChanging"
>>> "afterChange" or "onModelChanged"
>>>
>>
>> This really only works if you trust the listeners.  The browser core can't
>> trust scripted listeners using Web APIs.....
>>
> I don't understand what 'trust' means here.  I am not proposing any change
> to the privileges of listeners. How can the browser core "trust" an
> 'onModelChanged' listener but not an 'onModelChanging' listener?


If the user agent fires a modelChanging event, then the user agent must
verify that the pre-condition of removal is still met after the the event is
fired.  This is extremely hard to do and very error-prone.  Frankly, there's
no way we're adding such an event or callback.

On the other hand, firing modelChanged event asynchronously is an easy thing
to do because the user agent has already made the change and it doesn't need
to do any work after calling event listeners.

- Ryosuke
Received on Sunday, 3 July 2011 17:26:55 GMT

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