W3C home > Mailing lists > Public > www-svg@w3.org > September 2004

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

From: Jon Ferraiolo <jon.ferraiolo@adobe.com>
Date: Sat, 18 Sep 2004 09:34:03 -0700
To: Cameron McCormack <cam-www-svg@aka.mcc.id.au>, www-svg@w3.org
Message-id: <6.1.1.1.2.20040917182710.03c49000@mailsj-v1.corp.adobe.com>

Cameron,
Very good questions!

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

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.

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.

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.

All feedback is appreciated. I will forward this email to the XBL task 
force. Don't be surprised if the task force chooses a different option than 
what I propose.

Jon

At 05:05 PM 9/16/2004, Cameron McCormack wrote:

>Jon Ferraiolo:
> > Yes, if elements are added to the shadow tree via script, their
> > xblBoundElement points to the bound element just as if they were cloned
> > from the original <xbl:template> within the <xbl:definition>.
>
>Ok, thanks.
>
> > For example, let's say you have a binding definition that has no
> > <template>, such as:
> >
> >   <xbl:definition element="foo:bar">...</xbl:definition>
> >
> > And suppose you create an event listener in ECMAScript or Java which 
> listen
> > for the "bound" event, and further suppose that the handler associated 
> with
> > that event listener manually constructs the complete contents of
> > xblShadowTree by creating an <xbl:template> element and then attaching
> > children to the <xbl:template> such that xblShadowTree looks like this 
> when
> > everything is done:
>
>I didn't think it was possible to construct your own xbl:template
>element to use as a shadow tree, since the xblShadowTree attribute is
>readonly.  I assumed you'd have to use an empty xbl:template element in
>the definition, and then use script to add on to its clone.
>
>Cameron
>
>--
>Cameron McCormack
>|  Web: http://mcc.id.au/
>|  ICQ: 26955922
Received on Saturday, 18 September 2004 16:36:00 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:55 UTC