W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: Fwd: XBL2: First Thoughts and Use Cases

From: Dimitri Glazkov <dglazkov@google.com>
Date: Thu, 16 Dec 2010 15:08:26 -0800
Message-ID: <AANLkTikv6nX_L5a_dJ0naWLQsQ4S1i2_h8o1tZMScFF+@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, public-webapps <public-webapps@w3.org>
BTW, I moved the use cases page to
http://wiki.whatwg.org/wiki/XBL2UseCases. I ran through the discussion
and attempted to update the wiki with interesting outcomes. Please
feel free to edit/comment.

:DG<

On Thu, Dec 16, 2010 at 1:46 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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 23:08:56 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:42 GMT