HHirsch	has someone an idea how to get notified when someone (script, user through DOMi) changes the width and height of an svg element?
	darobin	yes, use mutation events
	HHirsch	how effective is the handling of mutation events? In my application there are probably around 100 elements for which I need to watch for mutation events. I cannot register only a single handler but instead need to install separate handlers on every element to watch (not all elements are being watched for). Any performance problems on the horizont?
	darobin	that really, really depends on the implementation
	HHirsch	on my side or mozilla's?
	darobin	but my rough educated guess would be that listening on 100 elements is better than listening on the whole document
	darobin	mozilla's
	darobin	or rather, listening in individual places instead of globally doesn't prevent certain optimizations
	darobin	but I don't know mozilla's implementation, so it might make no difference at all
	HHirsch	ah, I think I'm understanding ... I need to make sure that I'm not getting beaten by mutation events
	darobin	IME they haven't been a cause for concern
	HHirsch	okay, then I will try it (I just asked so to avoid jumping happily into well-known traps...)
	darobin	I've written apps with thousands of them, and the slowness was always due to redrawing, not to event handling
	HHirsch	now that should be more than sufficient for my simple purpose. Thanks!
	darobin	np
	HHirsch	wonders whether he can trigger more SVG bugs...
	HHirsch	remembers that Ford once tried to sell him to IBM's competitors because of finding AIX bugs in certified installations...
	bz	I can summarize Mozilla's implementation
	bz	if people care
	darobin	does
	HHirsch	does too (if it is about the mutation events)
	bz	When a DOM manipulation happens, we check with the Window object to see whether there are any mutation event handlers for that sort of DOM manipulation registered anywhere
	bz	(anywhere in the document, that is)
	bz	This is just a bit-flag check
	darobin	has found bugs in every single SVG implementation he's touched but no automotive BigCo has ever tried to enslave him to date
	bz	If there are, we walk the parent chain from the targeted object to the root, checking on each node whether it has a handler for that mutation event type
	bz	if it does, we stop
	bz	If we found a handler, we actually create and dispatch a DOM event targeted at the affected node
	bz	So an event is only dispatched if there is a mutation handler on an ancestor of the node (or node itself)
	darobin	ok, so local is indeed optimized
	bz	yeah
	darobin	that's good to know, thanks
	bz	And lack of event handlers is really optimized
	bz	one other thing
	bz	it's possible for the size of an <svg> to change without any mutation events...
	darobin	yes
	HHirsch	I remember XUL providing getter and setter functionality -- is the implementation somehow related to the mutation events infrastructure?
	darobin	you need to handle resize events too
	bz	HHirsch: what do you mean?
	HHirsch	oops, s/XUL/XBL/g
	bz	darobin: resize events on which object?
	bz	Ah
	darobin	HHirsch: could you be talking about XBL?
	bz	no, the XBL stuff is not related to mutation events
	darobin	ah yes
	darobin	bz: they only target the outermost svg element
	bz	darobin: oh, there are svg resize events. OK
	darobin	(like zoom)
	darobin	yeah, sorry, SVGResize and SVGZoom