Re: Fwd: XBL2: First Thoughts and Use Cases

On Thu, Dec 16, 2010 at 1:33 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 12/16/10 1:00 PM, Dimitri Glazkov wrote:
>>
>> I agree that it's going to be difficult to get this right, but
>> semi-live templates (if you change it here, it will reflect on all
>> instances, but it you change it here, it won't) seem even more
>> fragile.
>
> Sure.  I'm proposing that templates be completely dead.  I'm also proposing
> that, for a first cut, shadow trees be completely dead (in the "will throw
> exception if you try to add or remove nodes" sense), unless we can figure
> out how to efficiently implement live shadow trees.

Hmm.  Olli just said that shadow mutations are common in XBL1.  I'm
somewhat loathe to make it automatically dead.

On the other hand, there are lots of use-cases where dead shadows are
perfectly fine, so having some declarative way to differentiate
between whether the shadow needs to be live or dead might work.

For example, adding resize handles to an image doesn't require a live
shadow.  The handles can be static; they'll need listeners registered
on them, but that's it.  Same with <video> controls, or <select>
substructure.

It sounds like it's fine for the shadow to mutate, so long as nodes
aren't added/created/moved.  For example, I can twiddle attributes on
a shadow node without requiring the more expensive "map all the
metadata out" step, right?  The idea is just that we can, as an
optimization, keep all the metadata on a central shared object, so
that any time I, say, add a normal-DOM node to a component, I can just
go check that central data object to see where to forward the node?

~TJ

Received on Thursday, 16 December 2010 21:47:17 UTC