Re: xblShadowTree readonly? When does alternate rendering occur? xblBound boolean? (was Re: xblBoundElement in sXBL)

At 10:51 PM 9/18/2004, Cameron McCormack wrote:

>Jon Ferraiolo:
> > I think we definitely need to allow script writers to have the option of
> > total control of xblShadowTree. If they listen for the xbl:prebind or
> > xbl:bound events, the corresponding event handler should be able to define
> > the entire contents of xblShadowTree.
> >
> > But what is the best option for providing this ability? Here are some
> > options:
> >
> > 1) Make xblShadowTree read/write. This allows component developers to do
> > two things:
> >   a) Assign an appropriate <xbl:template> subtree via script in response
> > to an xbl:prebind or xbl:bound event.
> >   b) Set xblShadowTree to null as a convenient way to turn off rendering
> > for a bound element
>
>Seems like a good idea.  Would script-only generated shadow trees have
>to use xbl:template at the top of the shadow tree?

I would assume so. Most likely there would be an exception raised if you 
attached something other than an <xbl:template> to xblShadowTree. (I say 
most likely because the standards committees need to discuss this.)

>  Since all nodes in
>the document will implement NodeXBL, what happens if a shadow tree is
>assigned to a node that isn't an element?

Oh. I have always assumed that NodeXBL only applies to element nodes, 
despite its name. The sXBL specification doesn't say that NodeXBL only 
applies to elements, but the way sXBL in general and NodeXBL in particular 
is defined, it seems like it has to be restricted to element nodes. Once 
again, I will bring this up with the XBL committee.


> > 2) Keep xblShadowTree as readonly. If you ever want a shadow tree, then 
> you
> > must provide an <xbl:template> as a child of <xbl:definition>. If you want
> > to build the shadow tree from scratch via script, then put an
> > <xbl:template> as an empty element (i.e., <xbl:template/>) in your binding
> > document.
>
>I think it's silly to require an empty xbl:template element.
>
>There could be a third option, however: if no xbl:template element is
>given in the definition, an empty one is assumed.  Script could then add
>content to that.  If it was deemed important to keep xblShadowTree
>read only, this would be better than needing the empty xbl:template
>element.  Also, then there wouldn't be a problem with always having to
>create an xbl:template element in script yourself.  (The name 'template'
>would have lost its meaning, though.)

Actually, there have been complaints about the name <xbl:template> after 
the cloning. In RCC, we had a different name for the template and the root 
of the shadow tree. The template was a <prototype> element and the root of 
the shadow tree was either a <shadow> or a <shadowTree> element (I forget 
which). The RCC rules were that the contents of the <prototype> were cloned 
onto the <shadow> element.

I will bring up this naming confusion to the task force.


> > Personally, I prefer option #1 but both are workable.
> >
> > There is a related question. In the future with XBL 2.0, current thinking
> > is that we will want to offer the ability to attach XBL bindings to HTML
> > elements. For example, in XBL 2.0, we might want to bind a custom
> > presentation via a shadow to tree an <html:select> element. What 
> determines
> > whether to render the shadow tree or the original element? Here are two
> > options:
> >
> > A) If there is a binding definition which matches a given element (e.g.,
> > there is an <xbl:definition element="html:select">), then the binding
> > definition determines the rendering; else, render the original element.
> > When there is a binding definition, then if xblShadowTree is not null, 
> then
> > render the shadow tree; else (i.e., xblShadowTree is null), then nothing
> > gets rendered.
> >
> > B) Alternatively, if xblShadowTree is not null, then render the shadow
> > tree; else, render the original element.
> >
> > I like option A.
>
>I would have assumed B.  I don't think there is a good reason for
>restricting shadow tree rendering based on whether there is an XBL
>definition for that element.  Some other script, not related to that XBL
>definition, could define some different shadow tree for the element and
>it would then be rendered anyway.


My feeling is that option B complicates the processing model.

The XBL processing model is that the user agent maintains a table of active 
<xbl:definition> elements and the custom elements (foo:bar) that are 
associated with those <xbl:definition> elements. With sXBL, the only way to 
associate custom elements with <xbl:definition> binding definitions is the 
'element' attribute on <xbl:definition>. Going forward into XBL 2.0, the 
association most likely will be possible via CSS selectors and the 
'binding' property (assuming CSS is available). Both <xbl:definition 
element=...> and 'binding' would have the effect of updating the table.

Whenever elements are added to the document, the user agent refers to the 
binding table to decide if that element should be "bound" via XBL.

If you allow script to attach bindings outside of XBL, then you have to 
figure out how to resolve the conflicts. Suppose script attaches a binding 
manually to element <foo:bar>, and then the same script adds an 
<xbl:definition element="foo:bar"> to the document. Which one wins, the 
manually inserted xblShadowTree or the one that would be generated by the 
<xbl:definition> element? Note that sXBL has a processing model whereby any 
changes to the <xbl:definition> cause regeneration of the shadow trees for 
all of the bound elements that are associated with the <xbl:definition>. 
Here are some notes from section 4.1 (http://www.w3.org/TR/sXBL/#rules):

-------------------------------
When a <http://www.w3.org/TR/sXBL/#template0>template element is mutated in 
any way, any bindings whose shadow tree was constructed from that element 
must be reconstructed as described in this section.

If a <http://www.w3.org/TR/sXBL/#definition0>definition element that had no 
<http://www.w3.org/TR/sXBL/#template0>template element has a 
<http://www.w3.org/TR/sXBL/#template0>template element added, then a shadow 
tree is generated. If the <http://www.w3.org/TR/sXBL/#template0>template 
element is removed, then the shadow tree is destroyed.
-------------------------------

So, option B introduces complexities.


> > All of this makes me realize that it would be useful to add xblBound as a
> > readonly boolean attribute on NodeXML which indicates whether or not a
> > binding is attached to a given element.
>
>Or perhaps a reference to the actual binding that applies?

Yes, that would be better.

Jon


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