Re: Fwd: XBL2: First Thoughts and Use Cases

On Wed, Dec 15, 2010 at 10:19 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 12/15/10 7:51 AM, Tab Atkins Jr. wrote:
>> (Events and such don't work on the final flattened tree
>
> Sort of.  Hit testing clearly needs to work on the layout structure
> generated from the final flattened tree, so event target determination works
> on the flattened tree, while event propagation works on the shadow DOMs.
>
> What worries me is that if we bake this conceptual assumption about the
> shadow DOM nodes being distinct from the flattened tree elements that gives
> us the freedom to write a spec that in fact requires both to be represented
> by distinct objects, increasing the memory and complexity needed to
> implement.  More on this below.

True.  We need to dive into event handling a bit more and make sure
we're being consistent.  I suspect we are, but I need to make sure so
I can talk a consistent story.


>>> Should they be, though?  Should .childNodes.length on the parent of an
>>> output port in the flattened tree count the output port?
>>
>> Sure - from the perspective of the shadow node, it has some shadow
>> children, which may include output ports.
>
> So should the output port nodes then be exposed to methods manipulating the
> shadow DOM?  Should it be ok to move output ports around in the shadow tree?
>  If so, why?
>
> My preference, fwiw, would be that output ports are not present as DOM nodes
> in the shadow DOM.  That significantly reduces the complexity of specifying
> the behavior, I think....

Yes, output ports can be moved.  I don't have any particular use-case
for it, but under the current conceptual model for how output ports
work, it's simpler to allow it than to disallow it, because output
ports are just elements.

I think that having output ports be elements is a good and simple
answer, because we want output ports to be insertion points, not
containers.  Other answers are either incompatible (for example,
having a map of selectors to shadow nodes, which makes the pointed-to
shadow node a container) or more complicated (trying to match the
current shadow DOM to the template DOM to find out where the insertion
point should be).


>>> No.  The template is not "live" in the sense that it never mutates. It's
>>> a
>>> completely static DOM.
>>
>> Oh, gotcha.  Well, still, the problem arises from the (cloned)
>> template DOM and the shadow DOM being separate things that can drift
>> out of sync.  That's not what happens in our idea - the shadow is
>> cloned from the template, and then it's the only source of truth.
>
> So here's the thing.  XBL1 was originally designed as a reusable component
> model with the idea that the components would actually be reused, with
> possibly many (tens of thousands) of instantiations of a given template.
>  Which means that memory usage for each instantiation is a concern, which is
> why as much as possible is delegated to the shared state in the template.
>
> At least in Gecko's case, we still use XBL1 in this way, and those design
> goals would apply to XBL2 from our point of view.  It sounds like you have
> entirely different design goals, right?

Sounds like it.  We're approaching the problem from the angle of
"Every major javascript framework creates its own non-interoperable
component framework.  How can we make a lingua franca that would allow
them all to talk the same language?".  We want a jQuery component and
a MooTools component to work nicely together, rather than each having
their own entirely separate notion of what a "component" is, how to
manage its lifecycle, etc.

Under this model, existing components already expose all their DOM
separately every time, as real live DOM nodes in the document, so
instantiating fresh shadow for each instance of a component is no
worse.  Encapsulating it in shadow trees restores some sanity to the
DOM, and allows some optimizations (like not attempting to match
normal selectors against component-internal nodes, or
component-internal selectors against the rest of the page).

(Elaborating for the viewers at home, what I mean by "sanity" is the
nice hiding of inconsequential DOM that exists only for display and
interaction purposes.  For example, if you made <input type=range> in
normal HTML, you'd use a nice chunk of DOM structure for it.  The
details of exactly what the DOM is, though, are unimportant.  All you
need to know is that there's a slider input, and some relevant knobs
are exposed as attributes.  You don't want a rule from elsewhere in
the page accidentally styling the grabber for the slider just because
it happens to match "div > div" or something, *particularly* if
different browsers use different DOM structures for the slider input.)

~TJ

Received on Wednesday, 15 December 2010 18:51:57 UTC