Re: Mutation events replacement

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. The 
list of functions is not specified directly, but is implicit in the 
algorithm: some function's actions become asynchronous.  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. 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:23:30 UTC