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 11:03:29 -0800
Message-ID: <AANLkTik_e4K404PBAOOUnwy_72z2GLHG9LGvi9tk_a=H@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: robert@ocallahan.org, Dimitri Glazkov <dglazkov@google.com>, public-webapps <public-webapps@w3.org>
On Tue, Dec 14, 2010 at 10:45 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 12/14/10 10:25 AM, Tab Atkins Jr. wrote:
>> 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.
>
> Wait.  Are we talking about exposing details about the template to JS
> somewhere?  Where?  And why?

Well, not about the template itself.  But about the structure of the
template, and its effects on the shadow DOM.  (You might just be
referring to this, I dunno.)  Script should be able to walk and mutate
the shadow DOM for an element (if it hasn't been locked), add, remove,
or change output ports (where normal DOM children get "reparented"
into the shadow DOM for the final flattened tree), etc.

This info could just be exposed on the root element of the component
or whatever.  That's the thing that has the shadow DOM, after all.

As for why, I hopefully explained why I want this up above.  I believe
that this sort of functionality should be doable both declaratively
and from script.  Declarative is by far the easiest and clearest way
to do this sort of thing when you know what you're setting up
beforehand.  Both of those benefits turn negative the moment you try
to do something through script, though, because you have to pass
through the intermediary of the DOM, and because of magical effects
(like changing a template automagically mutating every element on the
page that uses that template).

By instead defining the base effects in terms of script interfaces,
and then defining how the declarative syntax is mapped into those
interfaces, we get the best of both worlds.  It's easy to read and
manipulate from script, since it was *designed* to be.  And it's still
easy to read and write declaratively and figure out what this means,
because the mapping between the declarative and the imperative syntax
is simple.  And you can even mix them easily, because the declarative
syntax is just used to initialize the script interfaces, which can
then be manipulated freely.

~TJ
Received on Tuesday, 14 December 2010 19:04:23 GMT

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