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

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?  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?

> 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.)

> 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.

> 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?

Cameron

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

Received on Sunday, 19 September 2004 05:51:10 UTC