Re: Mutation events replacement

On 7/4/11 12:23 PM, John J. Barton wrote:
> On 7/3/2011 1:23 PM, Boris Zbarsky wrote:
>> On 7/3/11 2:43 PM, John J. Barton wrote:
>>
>> I'm not sure what you're asking... The whole point of the proposed
>> model is that if someone tries to do a mutation the mutation _will_
>> happen and will complete. _Then_ listeners, if any, will be notified.
>> What are you worried about working or failing?
>
> According to Olli, some functions in mutation listeners will fail.

Pointer to where Olli said that, please?  I don't recall seeing anyone 
propose that....

> Silently changing the behavior of the API is not a good choice in my
> opinion.

We agree on that.

>> Now the developer of course wants to push as much of the cost of this
>> problem onto the UA as possible, and this makes sense: there are a lot
>> fewer UAs than developers.
> This has nothing to do with my perspective.

I didn't say anything about your perspective; just that this is the 
perspective of developers, on average, and that this perspective makes 
sense in general.

>> 4. Restrict any APIs that have this sort of power so they're not
>> usable by untrusted web pages (e.g. move them into browser extension
>> systems).
> If you can implement onModelChanging for extensions without crashing,
> then you can implement it for Web pages.

We can't implement it for extensions without crashing if the extension 
misbehaves, imo.

The difference is that we can't trust web pages to behave, ever.  On the 
other hand, a misbehaving extension can already cause so much grief that 
we have to trust it at _some_ level.

> There is also:
> 6. Leave the current Mutation event system as is.

The current Mutation system is broken by design for consumers and an 
endless source of pain for implementors.  I don't think anyone really 
wants to keep it as is.

> By restricting mutation listeners to explicitly avoid DOM mutation, the
> most sophisticated case is no different than the simple case. Then all
> three can be accommodated.

If such a restriction were feasible, it might be worth looking into.  It 
would involve not passing any DOM nodes to the mutation listener, I suspect.

-Boris

Received on Tuesday, 5 July 2011 01:39:47 UTC