Re: Fwd: XBL2: First Thoughts and Use Cases

On Wed, Dec 15, 2010 at 11:10 AM, Dimitri Glazkov <dglazkov@google.com> wrote:
> 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?

FWIW, this smells very CSS-ey.

>
>>>>> 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:12:15 UTC