On Jun 4, 2009, at 21:43 , Jonas Sicking wrote:
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).
Yeah, I definitely don't want to fore Attr nodes to be created just
for this.
The reason for not supplying the ns/ln pair is that this way we can
fire the callback just once even if multiple attributes were changed
during a "DOM operation".
I think that this is a sweep-under-the-rug optimisation. For certain
the dispatching will be faster, but the receiving end will have to
iterate (and memorise) all attributes each time one is changed. Why
not simply provide a list of ns/ln pairs? Presumably the
implementation knows that at little extra cost.
It's called with myNode. I actually got this wrong in the algorithm in
my initial proposal. Here is a fixed version:
Ok, cool with me.
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.
The only advantage I can see with this is that listeners that that
only care about the element tree, would avoid getting notified when
only non-element nodes were added or removed. The code in the listener
would be exactly the same. So it's strictly a performance
optimization.
On the flip side, for something like the innerHTML setter, the UA will
have to keep track of if the childlist used to contain any elements,
and then check if the new childlist contains any element. I'm not
convinced that this is worth it simply for a performance optimization.
At least not in the initial revision of this API.
Well if you care only about elements changing you might have to walk
the subtree to check that it was something else changing. But I don't
have a strong use case and I'm happy to start with something simpler
and toss in an element variant later if people scream.
Ah, yeah, we could fire it for changes to the target too.
Well, if you're firing on PIs it could be useful :)
Actually, target is readonly.
Duh!
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.
Note that the mutation event DOMCharacterDataModified fires on comment
nodes too. Has it been a problem there?
I always thought that was a bug :)
The only way I can think of people using either mutation the mutation
event, or this new API, is that once you get notified, you find the
node you are interested in, and then get that nodes .textContent. This
will work fine even the node being changed was a comment or PI.
I could live with a note in the specification saying that authors
should use .textContent as indeed it is the right protective thing to
do.
--
Robin Berjon - http://berjon.com/
Feel like hiring me? Go to http://robineko.com/