RE: removeChild and <use> question

I wasn't super clear here. The behavior we noticed wasn't in the DOM, but rather in the rendering.  It seems that some will render the content, while others do not.  

Thanks for all of the feedback. 

-----Original Message-----
From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf Of Alex Danilo
Sent: Wednesday, January 13, 2010 12:34 AM
To: Boris Zbarsky
Cc: Rick; www-svg
Subject: Re: removeChild and <use> question

Hi guys,

	Boris is 100% correct on this issue.

	The state of the DOM at any time after the removeChild call
should look like the element never existed when first parsed.
	
	Similarly, an appendChild() with an id matching the target
of the <use> should place the document into the state that the use
now points at the newly inserted node.

--Original Message--:
>On 1/12/10 6:13 PM, Rick wrote:
>> It's not unlikely that these concepts are under specified, or too
>> esoteric in the spec.  I haven't looked lately.
>
>Dynamic behavior tends to be underspecified in general, but the "no 
>hysteresis" rule is clear and simple to apply, and the only sane thing 
>to do.

I completely disagree it's underspecified.

Dynamic behaviour is perfectly specified. If you have a DOM
tree either by initial parse or subsequently after script
manipulation the state should be the same. If the engine
fails to visually display the same result for a set of DOM nodes due
to them being declaratively parsed versus created via script then
the engine has bugs, period.

For example, inserting an animation node on the fly should
be honoured but many implementations fail on that completely.

>> On the up side, It's cool that engines are advanced enough that this
>> issue is worthy of consideration.
>
>On the downside, it's sad that engines would implement SVG features, or 
>any other feature, without correct DOM update handling....  (And yes, 
>Gecko used to have bugs here too; we made fixing them a priority.)

Yes and I applaud you for doing so.

This doesn't really need any WG discussion, the behaviour
is well understood.

And for the record, the <use> node should never have been deleted
in Patrick's original example.

Patrick also noted "We also saw similar inconsistent behaviors
with events on <use>"

Yes, the WG discussed this exact issue back in 2006 and I
wrote a test for it back in 2006.

I don't know what ever happened to the test. But anyway, the
group's concensus at the time is in the minutes archive
but basically, the events bubble up through the <use>
element as if the shadow tree was a real tree. Some
implementations sent events all over the place!

Alex

>-Boris
>
>

Received on Wednesday, 13 January 2010 11:56:47 UTC