Re: Fwd: XBL2: First Thoughts and Use Cases

BTW, I moved the use cases page to I ran through the discussion
and attempted to update the wiki with interesting outcomes. Please
feel free to edit/comment.


On Thu, Dec 16, 2010 at 1:46 PM, Tab Atkins Jr. <> wrote:
> On Thu, Dec 16, 2010 at 1:33 PM, Boris Zbarsky <> 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 23:08:56 UTC