Re: Mutation events replacement

On Thu, Jun 4, 2009 at 3:56 AM, Robin Berjon <robin@berjon.com> wrote:
> Hey Jonas,
>
> nice proposal, overall I like it a lot.
>
> On Jun 4, 2009, at 11:07 , Jonas Sicking wrote:
>>
>> 'AttributeChanged': Called when an attribute on the node is changed.
>> This can be either a attribute addition, removal, or change in value.
>> If setAttribute is called the 'AttributeChanged' listener is always
>> called, even if the attribute is given the same value as it already
>> had. This is because it may be expensive to compare if the old and new
>> value was the same, if the value is internally stored in a parsed
>> form.
>
> I take it in this case the Attr node is what's passed? Might give a reason
> for its sorry existence :)

No, it'd be the element. The callback implementation would be
responsible for going through the attributes it is interested in and
take appropriate action based on their values.

>> 'ChildlistChanged': Called if one or or mode children are added or
>> removed to the node. So for example when innerHTML is set, replacing
>> 10 existing nodes with 20 new ones, only one call is made to the
>> 'ChildlistChanged' listeners on that node.
>>
>> 'SubtreeChanged': Same as 'ChildlistChanged', but called not just for
>> children added/removed to the node, but also to any descendants of the
>> node.
>
> If multiple nodes are changed at once, I'm guessing you call back with a
> DocumentFragment?

No, you always call back with the node who had children added or
removed to it. So if I do

myNode.innerHTML = "<i>hello</i>world<b>!</b>";

Then there would be only a single call to each callback with myNode
passed as node. Even though 3 nodes are inserted, and all existing
nodes were removed.

> For interoperability purposes, this would probably require
> a definition of what a single "DOM operation" is

Indeed we should.

> I'm thinking we might need ChildElementsChanged and ElementsSubtreeChanged
> that would handle only elements as well.

When would these be called? Why isn't ChildlistChanged enough?

>> 'TextDataChanged': Called when the data in a Text, CDATASection or
>> ProcessingInstruction, is changed on the node or any of its
>> decendants.
>
> Hmmmmm. If I set the listener on a PI, then I might be interested in this
> event — in which case it should be available on comment nodes too.

Ah, yes, I missed comment. Really it should be all CharacterData nodes
and all PIs.

> But then
> again, it seems to imply that I wouldn't get notified of changes to the PI's
> target.

Ah, yeah, we could fire it for changes to the target too.

> If on the other hand I listen to this on an element, I probably don't want
> to hear about changes made to PIs (or comments) in the subtree.

I think PIs and comments are changed rarely enough that this isn't
worth optimizing for. Unless you are worried about bugs somehow
arising?

I'm really trying to optimize for creating something simple and
performant here. As the proposal stands now, for all mutations a
minimal set of callbacks are fired. The only redundancy is that both
node-specific and whole-subtree listeners are fired. As opposed to the
DOM Mutation Events spec where for example a child insertion fires
DOMNodeInserted, DOMSubtreeModified and DOMNodeInsertedIntoDocument,
on the full parent chain.

/ Jonas

Received on Thursday, 4 June 2009 11:15:33 UTC