Re: Fwd: XBL2: First Thoughts and Use Cases

On Wed, Dec 15, 2010 at 10:51 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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).

I think Boris has the right preference. It's the solution that is not obvious :)

Conceptually, what we're talking here is some sort of insertion points that:
a) can be added between any two children;
b) aren't perceptible from DOM as elements or any other artifacts
c) have a clear set of rules governing how what happens to them during
sibling/parent mutation.

Right?

>>>> 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.)

And also yes, the use case of tens of thousands of instances is a
valid use case, with the same memory concerns as Boris stated.

:DG<

Received on Wednesday, 15 December 2010 19:11:13 UTC