Re: Mutation events replacement

On 7/3/2011 10:26 AM, Ryosuke Niwa wrote:
> On Sun, Jul 3, 2011 at 8:41 AM, John J. Barton 
> <johnjbarton@johnjbarton.com <mailto:johnjbarton@johnjbarton.com>> wrote:
>
>     On 7/2/2011 8:50 PM, Boris Zbarsky wrote:
>
>         On 7/2/11 1:46 PM, John J. Barton wrote:
>
>             2) element transformation. The replacement fires "after" a
>             mutation.
>             Library or tools that want to transform the application
>             dynamically want
>             to get notification "before" the mutation. A common
>             solution then is
>             to bracket changes:
>             "beforeChange" or "onModelChanging"
>             "afterChange" or "onModelChanged"
>
>
>         This really only works if you trust the listeners.  The
>         browser core can't trust scripted listeners using Web APIs.....
>
>     I don't understand what 'trust' means here.  I am not proposing
>     any change to the privileges of listeners. How can the browser
>     core "trust" an 'onModelChanged' listener but not an
>     'onModelChanging' listener?
>
>
> If the user agent fires a modelChanging event, then the user agent 
> must verify that the pre-condition of removal is still met after the 
> the event is fired.  This is extremely hard to do and very error-prone.
In the current proposal, the DOM API is manipulated while the 
onModelChange mutation listeners run. This manipulation ensures certain 
properties of the overall mutation process.  However the manipulation 
makes the API unreliable and the overall solution forces some use cases 
to adopt bizarre solutions.

I am not asking you to support onModelChanging with full DOM API access. 
I am asking you to take an open minded look at onModelChanging with 
manipulation of the API to maintain the pre-conditions you require.

Instead of surreptitiously changing the DOM API (to cause results to 
appear out of order), I am suggesting that the API be explicit. Rather 
than silently delaying the results of DOM mutations made in mutation 
event handlers, make the delay explicit. Force developers to delay 
mutations. Force developers to operate against your system the way you 
say they must, rather than pretending that they can mutate in mutation 
listeners.

Let's set the onModelChange/onModelChanging differences aside and focus 
just on the effective DOM API in mutation listeners. Your proposal is to 
change the DOM API experienced in listeners from the DOM API experiences 
outside of listeners.  The purpose is to control the order of DOM 
mutation.  You can achieve the same goal in other ways.

For example, consider WebWorkers. There we face a similar problem: the 
browser requires certain restrictions on the worker.  Direct DOM 
mutation must not be allowed. Developers have to work within these 
restrictions. Developing with WebWorkers is different from developing in 
web pages.  But the differences are clear and predictable.

In the present case, imagine that the mutation listeners have only one 
function call available: onNextTurn().   Their only option is to stage 
work based on the arguments to the listener. Within this model verifying 
preconditions is even easier than the current proposal *and* developers 
will have a reliable API.  This approach makes the properties of the 
platform explicit: no mutations within mutations.

jjb