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

Re: Fwd: XBL2: First Thoughts and Use Cases

From: Hajime Morita <morrita@google.com>
Date: Fri, 17 Dec 2010 11:28:55 +0900
Message-ID: <AANLkTi=nu5UY7w0QfoVbWjxg+oa40CYc2_mWq79LeQGd@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, Dimitri Glazkov <dglazkov@google.com>, public-webapps <public-webapps@w3.org>
Hi Tab,

On Fri, Dec 17, 2010 at 6:46 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> 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.
Please let me clarify - which can be done without live-ness?

- 1. Changing the tree structure (adding/removing the child)
- 2. Changing the attributes of the node (via setAttribute() or some
property access)
- 3. Changing the style directly (node.style property)
- 4. Changing the style declaratively (via modifying stylesheet)

It looks 4 is apparently OK, 3 might be OK, 1 and 2 is not allowed.
Is this right?

Note that editing text on <input> will cause 2 happen and
other form related changes as well.


> 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 Friday, 17 December 2010 02:30:28 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:28 UTC