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
