Re: XBL2: First Thoughts and Use Cases

On Mon, Dec 13, 2010 at 5:16 PM, Robert O'Callahan <> wrote:
> On Mon, Dec 13, 2010 at 5:12 AM, Dimitri Glazkov <>
> wrote:
>> > We definitely have use-cases that require the shadow DOM to be
>> > dynamically
>> > updated when an element that expands to a template instance has its
>> > subtree
>> > changed. Almost every application that combines dynamic DOM modification
>> > (e.g. editing) with templates needs this. So you do need to record how
>> > instances were created.
>> Can you give a more specific example?
> Suppose I use XBL2 to define <fancycontainer>, a container with elaborate
> styling that I can't do with CSS alone. Changes to the children of a
> <fancycontainer> need to be reflected in the shadow DOM tree built for
> <fancycontainer>, otherwise dynamic changes in the presence of
> <fancycontainer> are just broken. For example, adding a child to <container>
> would need to find the associated template instance and insert the child
> into the right place in the instance.

Ah, you're thinking about changes to the normal DOM.  We're afraid of
changes to the template.  Different story.

To be more specific, if we assume something like the following
(handwavey syntax):

<element name=x-fancycontainer>
    <div id=one>
      <div id=two>
        <div id=three>
          <content selector=*>


Then there's no problem.  You don't need the templates to be live to
make child changes work.  You just need to maintain some record that
any normal-DOM elements which match "*" should appear as children of
the shadow node #three in the final flattened tree.  appendChild()'ing
new elements to the x-fancycontainer will appropriately wire the
elements into the shadow tree.  This sort of selector->node map can be
divined from the template and copied into a separate data structure,
just like the actual shadow nodes can just be cloned out of the
template into separate live DOM.  No linkage back to the original
template is required.

We're just afraid of, say, attaching event handlers or data-*
attributes or whatever to shadow nodes, and then having the nodes get
destroyed and recreated underneath us when the <template> changes.  An
element shouldn't destroy itself unless the author explicitly tells it
to.  XBL does try to be careful to destroy as little as possible, but
it shouldn't destroy *anything* unless explicitly requested.


Received on Tuesday, 14 December 2010 01:47:40 UTC