On Jun 4, 2009, at 12:14 , Jonas Sicking wrote:
On Thu, Jun 4, 2009 at 3:56 AM, Robin Berjon <[email protected]> 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/
