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

Re: XBL2: First Thoughts and Use Cases

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 14 Dec 2010 10:25:23 -0800
Message-ID: <AANLkTikF7nvE63_HixVMs3Hr+CQw5Lx19816R0nqD7f4@mail.gmail.com>
To: robert@ocallahan.org
Cc: Dimitri Glazkov <dglazkov@google.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.
>
> But yeah, we're agreeing.

Begging the question.  ^_^

All of the information from the template can be duplicated in
appropriate data structures on the element itself, like Dimitri
explains.  This allows us to treat the template solely as a stamp,
used only at initialization and then thrown away.

This gains us a few things.  For one, you now have a simpler, more
static model of how things work.  There's no action-at-a-distance
where changes to the template late in the page lifecycle can affect
elements created during the original page parse; once an element is
created with the appropriate information, it stays that way forever,
unless the author explicitly monkeys around with it.  For two, it
naturally exposes all the magical template abilities to plain
javascript, allowing everything to be manipulated by script
after-the-fact, or even done entirely through script if that is, for
whatever reason, easier than writing a template into a page.  I think
this is A Good Thing(tm).  In general, I don't think we shouldn't be
adding new magical features to the platform without ensuring they can
be handled in script as well.

Looking just at the problem itself, it's an open question as to
whether it would be simpler to hold a reference to the template or
just create the appropriate data structures out of the template.
Likely, you'll be doing the latter in C++ anyway, so pushing them out
into js as well feels pretty natural.  But with the other added
benefits that you get from making everything happen "out in the open",
I think the decision is a lot clearer.

~TJ
Received on Tuesday, 14 December 2010 18:26:16 GMT

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