On 7/3/2011 10:26 AM, Ryosuke Niwa wrote:
On Sun, Jul 3, 2011 at 8:41 AM, John J. Barton
<johnjbar...@johnjbarton.com <mailto:johnjbar...@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
