Re: Mutation events replacement

On Jun 4, 2009, at 12:14 , Jonas Sicking wrote:
> On Thu, Jun 4, 2009 at 3:56 AM, Robin Berjon <robin@berjon.com> wrote:
>> 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.

That's annoying. I'm guessing that creating an Attr node just for this  
purpose is overhead we can live without given that they're never used,  
but it would be cheap (and dead useful) to include at least the  
attribute's name (ns/ln pair).

>>> '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.

So if I'm myNode's great-great-great-grand-mother and am watching  
SubtreeChanged do I get called with myNode or myself? I hope it's  
myNode, otherwise it's a bit useless.

>> 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?

I don't feel strongly about it — but it seems that every time we do  
something that's generic to nodes people come back and ask for an  
elements only variant, because that's what they actually use.

>>> '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.

I'm not sure, see below.

>> 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.

Well, if you're firing on PIs it could be useful :)

>> 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?

Precisely because they're rare, I'm worried about bugs when all of a  
sudden they're triggered. I think that there's a distinction (in  
authors' minds) between "content" — which includes text — and "the  
other stuff" — like PIs and comments. I think we should mirror that  
understanding, as it's rather sensible. It'd be a shame if 99.99% of  
code had to start with if (node.nodeType ==  
PROCESSING_INSTRUCTION_NODE || node.nodeType == COMMENT_NODE) return;  
and half of it forgot to.

> I'm really trying to optimize for creating something simple and
> performant here.

I'm all for that, but it should also be useful and simple to use :)

-- 
Robin Berjon - http://berjon.com/
     Feel like hiring me? Go to http://robineko.com/

Received on Thursday, 4 June 2009 13:32:01 UTC