Re: Confused about content in sXBL

Hi Cameron,
I will do my best to answer your questions.

At 10:47 PM 9/14/2004, Cameron McCormack wrote:

>I am confused about how the content element works in sXBL.  Am I right
>in thinking that when a shadow tree is generated, the content elements
>appear in the shadow tree's real DOM, and that these content elements
>act like a kind of use element in there, referencing the original
>elements in the XBL definition?  Or are those nodes cloned?

The xblShadowTree contains <content> elements. (Actually, clones of 
<content> elements. See below.)

The nodes which the <content> elements reference are not cloned.


>Looking at the diagram in 4.2 it shows that nodes 4 and 5 appear as
>children of one of the template (pink) nodes in the final flattened
>tree.  But are they actually the original DOM nodes that are the
>children of the bound element?  Or are they clones of these nodes?

The picture in section 4.2 is, for all intents and purposes, incorrect and 
obsolete. Our apologies!

Instead, the up-to-date processing model is described by the rest of the 
specification. I am pretty sure that the ugly ASCII pictures in 6.1.3 are 
accurate.

The current draft talks about two concepts: xblShadowTree (which contains 
<content> elements) and xblChildNodes (where the <content> elements have 
been flattened away and replaced by the things that they reference).

 From a scripting perspective, xblShadowTree is more primary than 
xblChildNodes (and xblFirstChild, etc.) in the sense that script can modify 
the topology of xblShadowTree, such as adding or deleting <content> 
elements, and you can modify the 'includes' attribute on <content> 
elements. If you do any of these modifications on xblShadowTree, 
xblChildNodes (and xblFirstChild, etc.) gets updated to reflect this. 
However, it doesn't work the other way around: you cannot use script to 
modify the topology of xblChildNodes (and xblFirstChild, etc.) - all of 
this topology is read-only.

My viewpoint (which isn't necessarily shared by everyone on the task force) 
is that xblShadowTree is *the* shadow tree, whereas xblChildNodes (and 
xblFirstChild, etc.) are just an alternate traversal mechanism to access 
nodes of interest. (But that might reflect might RCC-oriented mindset.)

>If they are clones, is the only way to access these clones through the
>xblChildNodes and other similar attributes?

As I mentioned above, there is no cloning of the elements referenced by 
<content> elements.

>Do these cloned nodes
>retain their original DOM relationship attributes (like nextSibling,
>etc.)?  What about a situation like this:
>
>   <g>
>     <my:something>
>       <svg:rect/>
>       <svg:circle/>
>     </my:something>
>   </g>
>
>where the template definition is
>
>   <template>
>     <content includes="svg:circle"/>
>     <content includes="svg:rect"/>
>   </template>
>
>if I get the xblChildNodes attribute of the g element to get the circle
>and rect, it will now be the case that circle.xblFollowingSibling ==
>rect and rect.xblPreviousSibling == circle.  But does
>rect.followingSibling == circle?  (Ignoring text nodes.)

In general, yes, but to be more precise:

   <g>
     <my:something id="boundelement">
        <svg:rect id="rect1"/>
        <svg:circle id="circle1"/>
     </my:something>
   </g>
   ...
   <template id="template1">
     <content id="content1" includes="svg:circle"/>
     <content id="content2" includes="svg:rect"/>
   </template>

When the shadow tree is built, you clone the template element and its 
children. The cloned shadow tree looks like this:

   template1Clone
     content1Clone
     content2Clone

Then you will have the following for xblShadowTree (assuming no text nodes):

   boundelement.xblShadowTree => template1Clone
   template1Clone.firstChild = content1Clone
   content1Clone.nextSibling = content2Clone
   content2Clone.previousSibling = content1Clone

And then the following for xblChildNodes/etc (assuming no text nodes)

   boundelement.xblFirstChild = circle1
   circle1.xblNextSibling = rect1
   rect1.xblPreviousSibling = circle1

Jon Ferraiolo
sXBL co-editor
Adobe Systems, Inc.



>Cameron
>
>--
>Cameron McCormack
>|  Web: http://mcc.id.au/
>|  ICQ: 26955922

Received on Wednesday, 15 September 2004 08:02:24 UTC