Re: Mutation events replacement

On 07/04/2011 07: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.
What? I don't understand this at all.


  The
> list of functions is not specified directly, but is implicit in the
> algorithm: some function's actions become asynchronous.
No. Change notifications are queued, and the listeners handling the
queue will called at the time when the outermost DOM mutation is about
to return.


-Olli


> This means one
> cannot write reliable code in mutation listeners and, worse, efforts to
> debug your failing code will fail. Code examples that work outside of
> mutation listeners will silently fail inside of mutation listeners.
>
> I have experience with these kinds of mysteriously-failing APIs in
> browser extension systems and that is why I am advocating against their
> inclusion in Web facing systems. If these already exist in the various
> browser implementations of Mutation events listeners, that does not mean
> its replacement should perpetuate the problem.
>
>>
>>> Ok, that's good, whatever it takes. A DOM API that switches between
>>> read-only and read-write would much better for developers than a DOM API
>>> that partly switches to async.
>>
>> Well, it sounds better to you. I'm not sure it sounds better to
>> "developers".
>>
>> If you think it's ok for assigning to a global variable to throw in a
>> mutation listener, and that this is better than some delay in the
>> listener firing (not actually async; Jonas' proposal doesn't really
>> fire things async, if you note), then I suspect developers might
>> disagree with you.
>
> The issue is not the delay in the listener firing. The issue is the
> effectively broken API within the listeners. Some functions called in
> listeners do not work the same way they do outside of listeners.
?


>
> Developers want a complete DOM API in mutation listeners.
Developers have complete DOM API in mutation listeners.
There are no restrictions.


> They can't
> have it. So the only question is how to express the restrictions.
> Silently changing the behavior of the API is not a good choice in my
> opinion.
>
>>
>>> Consider the alternative. In this use case, the developer wants to
>>> modify an execCommand. In the current replacement solution they have to
>>> wait for the execCommand to take effect, then undo the execCommand and
>>> redo it modified. Creating a good user experience may not be possible.
>>
>> Quite honestly, that's the developer's problem.
> No, it can't be the developer's problem because the current API does not
> allow the developer to fix the problem. I want to make it the
> developer's problem. I want to the developer to be able to reject
> operations before they commit because the alternative is to undo/redo.
>>
>> 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.
> ...
>> You're missing at least the following options:
>>
>> 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.
>> 5. Accept that certain levels of the platform just can't be hooked, at
>> least for the time being.
> There is also:
> 6. Leave the current Mutation event system as is.
>>
>> Again, I think trying to shoehorn all mutation consumers into the same
>> API is a bad idea that gave us the current mutation events. Some
>> consumers just want to know things have changed and not much more than
>> that. Some want to know details of the changes. Some want to rewrite
>> parts of the browser on the fly. It's not clear to me that the same
>> API for all three sets of consumers is the right solution.
> 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.
>
> jjb
>
>

Received on Monday, 4 July 2011 16:38:53 UTC