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

Re: XBL2: First Thoughts and Use Cases

From: Dimitri Glazkov <dglazkov@google.com>
Date: Tue, 14 Dec 2010 10:07:50 -0800
Message-ID: <AANLkTikmx4E=ATuLvjT3KSwnxLZVgN+7zQm=80h_DpPV@mail.gmail.com>
To: robert@ocallahan.org
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, public-webapps <public-webapps@w3.org>
On Mon, Dec 13, 2010 at 10:33 PM, Robert O'Callahan
<robert@ocallahan.org> wrote:
> On Tue, Dec 14, 2010 at 2:46 PM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>>
>> Then there's no problem.  You don't need the templates to be live to
>> make child changes work.  You just need to maintain some record that
>> any normal-DOM elements which match "*" should appear as children of
>> the shadow node #three in the final flattened tree.  appendChild()'ing
>> new elements to the x-fancycontainer will appropriately wire the
>> elements into the shadow tree.  This sort of selector->node map can be
>> divined from the template and copied into a separate data structure,
>> just like the actual shadow nodes can just be cloned out of the
>> template into separate live DOM.  No linkage back to the original
>> template is required.
>
> Sure, but you also have to handle the "includes" attribute and the
> "attributes" attribute, so in fact you need to know a fair bit about the
> template to handle dynamic changes to the bound document. You might decide
> it's easier to just hold a reference to the template itself.

If you indeed keep using "includes/locked", "attributes", and "pseudo"
from the template, you end up with a semi-live template, where
modifications to those values could affect the instances.

I think you'd be better off with something like this:

* Each bound instance holds data on how information (attribute values,
nodes, CSS pseudo-elements matching, etc.) is forwarded from the bound
element down to the the shadow subtree.
* During the binding phase, this information is populated by reading
corresponding attributes on the template.

This approach allows:
* Having a clean break between templates and instances.
* Allowing bound behaviors manipulate their forwarding at will,
without affecting the template.

Here's a mental model I would present to Web developers:
* The ability to influence a shadow DOM subtree from the outside is
provided by the Shadow DOM Forwarding.
* It's a list (array) of rules you associate with to the shadow DOM.
* Each rule specifies how a node, an attribute, a text node, current
language (and possibly direction), or a CSS pseudo selector is
forwarded from the bound element to the elements in the shadow
subtree.
* You can create this set of rules imperatively during the binding phase, or
* You can use templates to wire this up declaratively.
* You can modify the rules at any time while the shadow subtree
exists, but changes to rules are not retroactive.
* In other words, what's been forwarded is not re-forwarded or
affected in any way once the forwarding rule is changed or removed.

WDYT?

> But yeah, we're agreeing.
>
> Rob
> --
> "Now the Bereans were of more noble character than the Thessalonians, for
> they received the message with great eagerness and examined the Scriptures
> every day to see if what Paul said was true." [Acts 17:11]
>
Received on Tuesday, 14 December 2010 18:08:20 GMT

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