Re: Fwd: XBL2: First Thoughts and Use Cases
On 12/16/10 1:46 PM, Tab Atkins Jr. wrote: On Thu, Dec 16, 2010 at 1:33 PM, Boris Zbarskybzbar...@mit.edu wrote: On 12/16/10 1:00 PM, Dimitri Glazkov wrote: I agree that it's going to be difficult to get this right, but semi-live templates (if you change it here, it will reflect on all instances, but it you change it here, it won't) seem even more fragile. Sure. I'm proposing that templates be completely dead. I'm also proposing that, for a first cut, shadow trees be completely dead (in the will throw exception if you try to add or remove nodes sense), unless we can figure out how to efficiently implement live shadow trees. Hmm. Olli just said that shadow mutations are common in XBL1. I'm somewhat loathe to make it automatically dead. OK. I can see that. Certainly a binding like Firefox's tabbrowser needs to be able to modify its DOM (e.g. to add the new tab)... We could restrict this further by only disallowing mutations that affect output ports, but that could be confusing to spec and author to (though in practice, users of Mozilla XBL author under just such a restriction, in that if they do something that does affect output ports things break). On the other hand, there are lots of use-cases where dead shadows are perfectly fine, so having some declarative way to differentiate between whether the shadow needs to be live or dead might work. Hmm. Yeah, that might work. It sounds like it's fine for the shadow to mutate, so long as nodes aren't added/created/moved. And removed, yes. For example, I can twiddle attributes on a shadow node without requiring the more expensive map all the metadata out step, right? Yes. The idea is just that we can, as an optimization, keep all the metadata on a central shared object, so that any time I, say, add a normal-DOM node to a component, I can just go check that central data object to see where to forward the node? Yep. I suppose one could have a COW scheme where the metadata is cloned on mutation, but that requires a check on every mutation and makes it very easy to accidentally deoptimize... Maybe that's ok. -Boris
Re: Fwd: XBL2: First Thoughts and Use Cases
Boris, Tab, thank you for clarification. I was confusing template and non-template (content) part of the shadow tree.. For template, it makes sense to let them dead and freeze the structure. -- morrita On Sat, Dec 18, 2010 at 2:35 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Dec 16, 2010 at 6:28 PM, Hajime Morita morr...@google.com wrote: Hi Tab, On Fri, Dec 17, 2010 at 6:46 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: Sure. I'm proposing that templates be completely dead. I'm also proposing that, for a first cut, shadow trees be completely dead (in the will throw exception if you try to add or remove nodes sense), unless we can figure out how to efficiently implement live shadow trees. Please let me clarify - which can be done without live-ness? - 1. Changing the tree structure (adding/removing the child) - 2. Changing the attributes of the node (via setAttribute() or some property access) - 3. Changing the style directly (node.style property) - 4. Changing the style declaratively (via modifying stylesheet) It looks 4 is apparently OK, 3 might be OK, 1 and 2 is not allowed. Is this right? Note that editing text on input will cause 2 happen and other form related changes as well. Like Boris said, #1 is the only problem. We're only trying to make it so that the metadata we copy out of the template can be shared (the list of output ports and the list of attribute forwards, I think), and to do that we just need to freeze the structure of the DOM. If the output port is done as an element that you can see in the shadow DOM, then we need to freeze the selector it uses to match and any other switches expressed as attributes on it. ~TJ ~TJ -- morrita
Re: Fwd: XBL2: First Thoughts and Use Cases
On 12/15/10 11:29 AM, Dimitri Glazkov wrote: That seems like an implementation detail. Metadata can be shared and cloned as needed, just like styles in CSS. Sort of. It would need to be cloned as soon as the shadow tree is mutated, right? That seems like very fragile behavior from a web author point of view, where it's easy to deoptimize without realizing it. -Boris
Re: Fwd: XBL2: First Thoughts and Use Cases
On Thu, Dec 16, 2010 at 10:40 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/15/10 11:29 AM, Dimitri Glazkov wrote: That seems like an implementation detail. Metadata can be shared and cloned as needed, just like styles in CSS. Sort of. It would need to be cloned as soon as the shadow tree is mutated, right? That seems like very fragile behavior from a web author point of view, where it's easy to deoptimize without realizing it. At least we can produce simple advice on how to definitely avoid deoptimizing - stick with the declarative syntax and don't mutate the shadow. With luck, enough use-cases will be solveable with the declarative syntax that this will be an acceptable restriction. ~TJ
Re: Fwd: XBL2: First Thoughts and Use Cases
On 12/16/2010 11:52 AM, Tab Atkins Jr. wrote: On Thu, Dec 16, 2010 at 10:40 AM, Boris Zbarskybzbar...@mit.edu wrote: On 12/15/10 11:29 AM, Dimitri Glazkov wrote: That seems like an implementation detail. Metadata can be shared and cloned as needed, just like styles in CSS. Sort of. It would need to be cloned as soon as the shadow tree is mutated, right? That seems like very fragile behavior from a web author point of view, where it's easy to deoptimize without realizing it. At least we can produce simple advice on how to definitely avoid deoptimizing - stick with the declarative syntax and don't mutate the shadow. With luck, enough use-cases will be solveable with the declarative syntax that this will be an acceptable restriction. Well, at least with XBL1 modifying the shadow tree is very common. And I would assume that to be rather common with XBL2 too. -Olli ~TJ
Re: Fwd: XBL2: First Thoughts and Use Cases
On Thu, Dec 16, 2010 at 10:40 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/15/10 11:29 AM, Dimitri Glazkov wrote: That seems like an implementation detail. Metadata can be shared and cloned as needed, just like styles in CSS. Sort of. It would need to be cloned as soon as the shadow tree is mutated, right? That seems like very fragile behavior from a web author point of view, where it's easy to deoptimize without realizing it. I agree that it's going to be difficult to get this right, but semi-live templates (if you change it here, it will reflect on all instances, but it you change it here, it won't) seem even more fragile. That's why Hixie made XBL2's templates always-live, I think. But I totally get the need of coming up with a solution that doesn't end up being a memory hog. :DG -Boris
Re: Fwd: XBL2: First Thoughts and Use Cases
On Thu, Dec 16, 2010 at 12:23 PM, Olli Pettay olli.pet...@helsinki.fi wrote: On 12/16/2010 11:52 AM, Tab Atkins Jr. wrote: On Thu, Dec 16, 2010 at 10:40 AM, Boris Zbarskybzbar...@mit.edu wrote: On 12/15/10 11:29 AM, Dimitri Glazkov wrote: That seems like an implementation detail. Metadata can be shared and cloned as needed, just like styles in CSS. Sort of. It would need to be cloned as soon as the shadow tree is mutated, right? That seems like very fragile behavior from a web author point of view, where it's easy to deoptimize without realizing it. At least we can produce simple advice on how to definitely avoid deoptimizing - stick with the declarative syntax and don't mutate the shadow. With luck, enough use-cases will be solveable with the declarative syntax that this will be an acceptable restriction. Well, at least with XBL1 modifying the shadow tree is very common. And I would assume that to be rather common with XBL2 too. Yes. -Olli ~TJ
Re: Fwd: XBL2: First Thoughts and Use Cases
On 12/16/10 1:00 PM, Dimitri Glazkov wrote: I agree that it's going to be difficult to get this right, but semi-live templates (if you change it here, it will reflect on all instances, but it you change it here, it won't) seem even more fragile. Sure. I'm proposing that templates be completely dead. I'm also proposing that, for a first cut, shadow trees be completely dead (in the will throw exception if you try to add or remove nodes sense), unless we can figure out how to efficiently implement live shadow trees. -Boris
Re: Fwd: XBL2: First Thoughts and Use Cases
On Thu, Dec 16, 2010 at 1:33 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/16/10 1:00 PM, Dimitri Glazkov wrote: I agree that it's going to be difficult to get this right, but semi-live templates (if you change it here, it will reflect on all instances, but it you change it here, it won't) seem even more fragile. Sure. I'm proposing that templates be completely dead. I'm also proposing that, for a first cut, shadow trees be completely dead (in the will throw exception if you try to add or remove nodes sense), unless we can figure out how to efficiently implement live shadow trees. Hmm. Olli just said that shadow mutations are common in XBL1. I'm somewhat loathe to make it automatically dead. On the other hand, there are lots of use-cases where dead shadows are perfectly fine, so having some declarative way to differentiate between whether the shadow needs to be live or dead might work. For example, adding resize handles to an image doesn't require a live shadow. The handles can be static; they'll need listeners registered on them, but that's it. Same with video controls, or select substructure. It sounds like it's fine for the shadow to mutate, so long as nodes aren't added/created/moved. For example, I can twiddle attributes on a shadow node without requiring the more expensive map all the metadata out step, right? The idea is just that we can, as an optimization, keep all the metadata on a central shared object, so that any time I, say, add a normal-DOM node to a component, I can just go check that central data object to see where to forward the node? ~TJ
Fwd: XBL2: First Thoughts and Use Cases
On Tue, Dec 14, 2010 at 10:32 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/14/10 10:08 PM, Tab Atkins Jr. wrote: Hm, good point. So then, no, there has to be an element in the shadow DOM that represents an output port, which is then *replaced* with the appropriate normal-DOM children in the final flattened tree. So just to make sure we're on the same page... are you thinking in terms of there being separate DOM nodes in the template, in the shadow DOM and in the final flattened tree? Yes to the first two. Maybe to the last - the final flattened tree is just what's handed to CSS as the element-tree. There aren't really DOM nodes there, or at least it doesn't matter whether or not there is. (Events and such don't work on the final flattened tree, they work on the DOM augmented with shadow DOMs, in such a way that the existence of shadow DOMs isn't revealed to elements that don't need to know about them.) content div span/span children/ span/span /div content And then you remove the first span. So that in this case there would be a span element in the shadow DOM and a different span element in the flattened tree? Subject to what I said above, maybe? Ah, ok. Given what I said above (shadow node representing the port, which is replaced in the final flattened tree), then this is trivial. Removing the first span would just change the shadow to be: div outputport span/span /div OK; how would it change the flattened tree? Or am I misunderstanding your conceptual model? The final flattened tree wouldn't have the first original first span, since it's not in the DOM anymore. It would just look like: div ...any normal-DOM elements associated with the output port... span/span /div Hopefully this is the obvious answer. ...exactly as expected, since you're just mutating a DOM, and output ports are real DOM nodes. 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. The shadow doesn't directly know whether its output port has any normal-DOM elements associated with it, or how many, though this is something you should be able to easily query with script (possibly a property on the output port returning a NodeList of normal-DOM elements associated with it). The way Gecko's implementation works if one can call it that is that there is the template DOM and then the shadow DOM. The shadow DOM is created by cloning the template DOM, more or less. Output ports are kept track of on the template DOM. When you insert a node as a child under the bind element, you find the right port in the template DOM, then try to find the corresponding location in the (possibly mutated) shadow DOM. This clearly doesn't work very well! Ah, so it *is* an issue with combining mutable shadows with live templates! 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. ~TJ
Re: Fwd: XBL2: First Thoughts and Use Cases
On 12/15/10 7:51 AM, Tab Atkins Jr. wrote: Yes to the first two. Maybe to the last - the final flattened tree is just what's handed to CSS as the element-tree. There aren't really DOM nodes there, or at least it doesn't matter whether or not there is. OK. (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. Ah, ok. Given what I said above (shadow node representing the port, which is replaced in the final flattened tree), then this is trivial. Removing the first span would just change the shadow to be: div outputport span/span /div OK; how would it change the flattened tree? Or am I misunderstanding your conceptual model? The final flattened tree wouldn't have the first original first span, since it's not in the DOM anymore. It would just look like: div ...any normal-DOM elements associated with the output port... span/span /div Hopefully this is the obvious answer. Well... it's the desired answer. It wasn't obvious from your formulation, no. 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 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? -Boris
Re: Fwd: XBL2: First Thoughts and Use Cases
On Wed, Dec 15, 2010 at 10:19 AM, Boris Zbarsky bzbar...@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
Re: Fwd: XBL2: First Thoughts and Use Cases
On Wed, Dec 15, 2010 at 10:51 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Dec 15, 2010 at 10:19 AM, Boris Zbarsky bzbar...@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
Re: Fwd: XBL2: First Thoughts and Use Cases
On Wed, Dec 15, 2010 at 11:10 AM, Dimitri Glazkov dglaz...@google.com wrote: On Wed, Dec 15, 2010 at 10:51 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Dec 15, 2010 at 10:19 AM, Boris Zbarsky bzbar...@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
Re: Fwd: XBL2: First Thoughts and Use Cases
On 12/15/10 10:51 AM, Tab Atkins Jr. wrote: 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. It significantly complicates implementation; when an output port is moved you have to find all the elements in the flattened tree that came through the output port and move them to different places (note that they don't all end up in the same place, in general). 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. Sure. But them being insertion points can happen without being elements. For example, an insertion point can be tracked conceptually as a collapsed range (e.g. similar to the way a caret works in text controls; that too is an insertion point). 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. OK, so given contradictory design goals, where do we go from here? 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. Sure. And Gecko instantiates a fresh shadow tree copy for each instance. However you're suggesting also instantiating a fresh copy of various metadata, whose size can easily dwarf the size of the shadow tree itself. -Boris
Re: Fwd: XBL2: First Thoughts and Use Cases
On Wed, Dec 15, 2010 at 11:14 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/15/10 10:51 AM, Tab Atkins Jr. wrote: 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. It significantly complicates implementation; when an output port is moved you have to find all the elements in the flattened tree that came through the output port and move them to different places (note that they don't all end up in the same place, in general). 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. Sure. But them being insertion points can happen without being elements. For example, an insertion point can be tracked conceptually as a collapsed range (e.g. similar to the way a caret works in text controls; that too is an insertion point). 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. OK, so given contradictory design goals, where do we go from here? I don't understand how the goals are contradictory -- and to be honest, I can't see how anyone could understand this without a set of use cases. Can we instead focus on use cases and then decide? :) 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. Sure. And Gecko instantiates a fresh shadow tree copy for each instance. However you're suggesting also instantiating a fresh copy of various metadata, whose size can easily dwarf the size of the shadow tree itself. That seems like an implementation detail. Metadata can be shared and cloned as needed, just like styles in CSS. -Boris
Re: Fwd: XBL2: First Thoughts and Use Cases
On Wed, Dec 15, 2010 at 11:14 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/15/10 10:51 AM, Tab Atkins Jr. wrote: 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. It significantly complicates implementation; when an output port is moved you have to find all the elements in the flattened tree that came through the output port and move them to different places (note that they don't all end up in the same place, in general). If all you're doing is moving the output port, why wouldn't all the associated normal-DOM elements end up in the same place? Mutating the output port would obviously cause changes, and the final box-tree for CSS can indeed be changed in non-trivial ways, but I'm not immediately seeing any reason why the final flattened tree would be changed in any extraordinary way. 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. Sure. But them being insertion points can happen without being elements. For example, an insertion point can be tracked conceptually as a collapsed range (e.g. similar to the way a caret works in text controls; that too is an insertion point). True, but having them be anything other than elements complicates the handling of shadow DOM mutations. I don't think there's a non-arbitrary answer to what happens if the shadow tree contains *only* an output port (as a collapsed range) and then you append a child to the shadow tree. Does the range go before or after the node? Is there any way to make this obvious to an author? I'm not wedded to the output ports are elements in the shadow DOM idea, but I think it's a pretty strong idea. 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. OK, so given contradictory design goals, where do we go from here? Hmm, good question. To start, I don't think I fully understand the value of the situation you outline as a design goal. What sort of situation do you envision where you want to optimize producing tens of thousands of components on a single page? In the long term, if our use-cases truly are contradictory or incompatible, then we can decide if it's worthwhile to approach each case independently with different solutions. We need to look at use-cases first, though, so we can decide exactly what problems we're trying to solve. 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. Sure. And Gecko instantiates a fresh shadow tree copy for each instance. However you're suggesting also instantiating a fresh copy of various metadata, whose size can easily dwarf the size of the shadow tree itself. I don't think I agree with that characterization. The necessary metadata isn't very large: 1. A list of output ports. 2. For each output port, a list of which normal-DOM descendants of the component are associated with that port. 3. A list of attribute forwards (a map from name to node/name). 4. A list of pseudos (a map from idents to shadow nodes). 5. Other stuff? This is a few NodeLists and a few maps, comparable in size to a small DOM tree I'd think. Am I missing something? ~TJ
Re: Fwd: XBL2: First Thoughts and Use Cases
On 12/15/10 11:40 AM, Tab Atkins Jr. wrote: If all you're doing is moving the output port, why wouldn't all the associated normal-DOM elements end up in the same place? Because the new parent of the output port can have a binding attached itself, which puts them in different output ports under that shadow tree. True, but having them be anything other than elements complicates the handling of shadow DOM mutations. I'm still looking for use cases for shadow DOM mutations that involve adding or removing nodes. Why are these useful? If they're not sufficiently useful, then given the specification and implementation complexity of supporting them I would propose that they be disallowed. I don't think there's a non-arbitrary answer to what happens if the shadow tree contains *only* an output port (as a collapsed range) and then you append a child to the shadow tree. Does the range go before or after the node? The range spec defines this, fwiw... ;) But yes, there is less author control in this case; you can't choose whether the node goes before or after the port. OK, so given contradictory design goals, where do we go from here? Hmm, good question. To start, I don't think I fully understand the value of the situation you outline as a design goal. What sort of situation do you envision where you want to optimize producing tens of thousands of components on a single page? A component attached to every table cell in a large data table, say. Or every email in your inbox. Or every text input or checkbox or dropdown select (see Slashdot comment page while moderating). These are all situations where I've seen people trying to use XBL1, fwiw. In the long term, if our use-cases truly are contradictory or incompatible, then we can decide if it's worthwhile to approach each case independently with different solutions. We need to look at use-cases first, though, so we can decide exactly what problems we're trying to solve. Agreed. I don't think I agree with that characterization. The necessary metadata isn't very large: 1. A list of output ports. 2. For each output port, a list of which normal-DOM descendants of the component are associated with that port. 3. A list of attribute forwards (a map from name to node/name). 4. A list of pseudos (a map from idents to shadow nodes). 5. Other stuff? For each output port the relevant CSS selectors. This is a few NodeLists and a few maps, comparable in size to a small DOM tree I'd think. A DOM tree in Gecko takes order of 40 bytes per node. Just storing a single nontrivial CSS selector is comparable in size to a bunch of DOM nodes, last I checked. -Boris
