W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: Mutation events replacement

From: Rafael Weinstein <rafaelw@google.com>
Date: Wed, 10 Aug 2011 14:01:54 -0700
Message-ID: <CABMdHiS-MErAj8ZMvvTxJfwUr2JmKDny3=ijTtjnGprEh1ed=g@mail.gmail.com>
To: olli@pettay.fi
Cc: public-webapps@w3.org
Awesome. Status update on our side:

-Adam has been researching the implementation implications in Webkit
of a few variants of proposals made here -- with the goal of having
enough understanding to start a discussion on webkit-dev.

-I'm composing an email which attempts to summarize the discussion so
far, the points of broad agreement and the remaining points of
divergence -- with the goal of trying to drive to an initial consensus
on the main design points of a replacement.

-I've been experimenting with implementing various "net effect
projections" that take sequences of mutations as input -- with the
goal of reporting back on the time/space complexity implications for
variants of what information is provided in the mutation records.

Cheers
Rafael

On Wed, Aug 10, 2011 at 12:49 PM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:
> FYI, I'm planning to implement the proposal (using vendor prefixed API)
> so that I can create "tryserver" builds.
> I'll post the links to builds here later, hopefully in a few days, when
> I find the time to do the actual implementation.
>
>
> -Olli
>
>
> On 08/04/2011 04:38 PM, Olli Pettay wrote:
>>
>> Hi all,
>>
>> here is a bit different proposal for mutation events replacement.
>> This is using the mostly-sync approach, and batching can make it easier
>> to use with several simultaneous script libraries; each one would use
>> their own batch.
>> For performance reasons it might be useful to have an attribute name
>> filter for AttrChange, but such thing could be added later.
>> One advantage this approach has is that it doesn't pollute Node API.
>>
>>
>> -Olli
>>
>>
>>
>>
>> interface Modification {
>> /**
>> * type is either TextChange, ChildListChange or AttrChange.
>> * (More types can be added later if needed.)
>> */
>> readonly attribute DOMString type;
>>
>> /**
>> * Target of the change.
>> * If an attribute is changed, target is the element,
>> * if an element is added or removed, target is the node
>> * which was added or removed.
>> * If text is changed, target is the CharacterData node which was
>> * changed.
>> */
>> readonly attribute Node target;
>> /**
>> * parent node of the target right before the change happened,
>> * or null.
>> */
>> readonly attribute Node targetParent;
>> /**
>> * The node which is "batching" the change.
>> */
>> readonly attribute Node currentTarget;
>>
>> /**
>> * The name of the attribute which was changed, or null.
>> */
>> readonly attribute DOMString attrName;
>>
>> /*
>> * The previous value of the attribute or CharacterData node, or null.
>> * If a new attribute is added, prevValue is null.
>> */
>> readonly attribute DOMString prevValue;
>>
>> /*
>> * The new value of the attribute or CharacterData node, or null.
>> * If an attribute is removed, newValue is null.
>> */
>> readonly attribute DOMString newValue;
>> };
>>
>> [Callback, NoInterfaceObject]
>> interface ModificationCallback {
>> void handleBatch(in ModificationBatch aBatch);
>> };
>>
>> [Constructor(in ModificationCallback aDoneCallback)]
>> interface ModificationBatch {
>> /**
>> * Modifications is non-empty array only while aDoneCallback
>> * is called. And while that happens, modifications list doesn't
>> * change.
>> */
>> readonly attribute Modification[] modifications;
>>
>> void batchTextChanges(in Node aNode);
>> void unbatchTextChanges(in Node aNode);
>>
>> void batchChildListChanges(in Node aNode);
>> void unbatchChildListChanges(in Node aNode);
>>
>> void batchAttrChanges(in Node aNode);
>> void unbatchAttrChanges(in Node aNode);
>>
>> void batchAll();
>> void unbatchAll();
>> };
>>
>> aDoneCallback is called right before the call which is modifying DOM
>> returns. If aDoneCallback modifies DOM, new modifications list will be
>> collected
>> and callbacks will be called right after the initial aDoneCallback
>> returns.
>> ModificationBatches are always handled in the order they are *created*.
>> Callbacks are never called if modifications list is empty.
>>
>>
>> Example 1:
>> // log all the attribute changes
>> var o = new ModificationBatch(function(b) {
>> for (var i = 0; i < b.modifications.length; ++i) {
>> var m = b.modifications[i];
>> if (m.prevValue == null) {
>> console.log(m.attrName + " added");
>> } else if (m.newValue == null) {
>> console.log(m.attrName + " removed");
>> } else {
>> console.log(m.attrName + " modified");
>> }
>> }
>> }
>> );
>> o.batchAttrChanges(document);
>>
>>
>>
>>
>
>
>
Received on Wednesday, 10 August 2011 21:02:29 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT