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

Re: Fwd: XBL2: First Thoughts and Use Cases

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 17 Dec 2010 09:35:26 -0800
Message-ID: <AANLkTimb1q_RPbbMfWe5bhC9UY8F1wTQWjvtywKThNdO@mail.gmail.com>
To: Hajime Morita <morrita@google.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, Dimitri Glazkov <dglazkov@google.com>, public-webapps <public-webapps@w3.org>
On Thu, Dec 16, 2010 at 6:28 PM, Hajime Morita <morrita@google.com> wrote:
> 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.

Like Boris said, #1 is the only problem.  We're only trying to make it
so that the metadata we copy out of the template can be shared (the
list of output ports and the list of attribute forwards, I think), and
to do that we just need to freeze the structure of the DOM.

If the output port is done as an element that you can see in the
shadow DOM, then we need to freeze the selector it uses to match and
any other switches expressed as attributes on it.

~TJ

~TJ
Received on Friday, 17 December 2010 17:36:19 GMT

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