- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Mon, 04 Jul 2011 19:38:25 +0300
- To: johnjbarton@johnjbarton.com
- CC: public-webapps@w3.org
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