Re: XBL2: First Thoughts and Use Cases
On 12/15/10 10:53 PM, Maciej Stachowiak wrote: Are they really contradictory? Good question. ;) If they aren't, great. Personally, I think it would be a huge win if XBL2-based components could be more scalable than ones written in pure JavaScript using vanilla DOM calls. That way, XBL2 could enable new kinds of applications and reduce memory use of existing applications, rather than just providing convenience and bridging, as Tab seems to envision. Right; I think we're on the same page there. -Boris
Re: XBL2: First Thoughts and Use Cases
On Wed, Dec 15, 2010 at 10:53 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 15, 2010, at 11:14 AM, Boris Zbarsky wrote: 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? Are they really contradictory? It sounds like Tab doesn't care about the use case where you want hundreds or thousands of instances without undue memory use, since he's looking to replace technologies that already don't support this. But it doesn't seem like these use cases are fundamentally incompatible. Personally, I think it would be a huge win if XBL2-based components could be more scalable than ones written in pure JavaScript using vanilla DOM calls. That way, XBL2 could enable new kinds of applications and reduce memory use of existing applications, rather than just providing convenience and bridging, as Tab seems to envision. FWIW, I think Tab agrees with you here (right, Tab? :). If you want to introduce new capabilities, might as well make them lean and mean. :DG Regards, Maciej
Re: XBL2: First Thoughts and Use Cases
On Tue, 14 Dec 2010, Boris Zbarsky wrote: So that in this case there would be a span element in the shadow DOM and a different span element in the flattened tree? As XBL2 is specced currently, the nodes in the explicit DOM and in the shadow DOM are the same nodes as in the final flattened tree, except that certain elements in the shadow tree don't appear in the final flattened tree (the root template and the insertion point content elements, in particular; also the element used for inheritance insertion). The example in this section, while initially rather perplexing, is probably the quickest way of visualising this: http://dev.w3.org/cvsweb/~checkout~/2006/xbl2/Overview.html?content-type=text/html;%20charset=utf-8#the-final-flattened-tree The key is just that each element in the final flattened tree is _also_ in a DOM somewhere. It's the same elements, they just have two sets of tree pointers (parent, children, siblings, etc). Selectors and events work in XBL2 as specified work on a carefully chosen hybrid of these trees. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XBL2: First Thoughts and Use Cases
On Wed, Dec 15, 2010 at 1:18 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 14 Dec 2010, Boris Zbarsky wrote: So that in this case there would be a span element in the shadow DOM and a different span element in the flattened tree? As XBL2 is specced currently, the nodes in the explicit DOM and in the shadow DOM are the same nodes as in the final flattened tree, except that certain elements in the shadow tree don't appear in the final flattened tree (the root template and the insertion point content elements, in particular; also the element used for inheritance insertion). The example in this section, while initially rather perplexing, is probably the quickest way of visualising this: http://dev.w3.org/cvsweb/~checkout~/2006/xbl2/Overview.html?content-type=text/html;%20charset=utf-8#the-final-flattened-tree The key is just that each element in the final flattened tree is _also_ in a DOM somewhere. It's the same elements, they just have two sets of tree pointers (parent, children, siblings, etc). Selectors and events work in XBL2 as specified work on a carefully chosen hybrid of these trees. As far as I know (and I've been in the center of the discussions over here, so hopefully I know pretty far), we agree with this design in XBL2. We have some nits to pick with precisely how shadows are constructed and flattened, but otherwise, yeah, basically the same deal. ~TJ
Re: XBL2: First Thoughts and Use Cases
On Dec 15, 2010, at 11:14 AM, Boris Zbarsky wrote: 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? Are they really contradictory? It sounds like Tab doesn't care about the use case where you want hundreds or thousands of instances without undue memory use, since he's looking to replace technologies that already don't support this. But it doesn't seem like these use cases are fundamentally incompatible. Personally, I think it would be a huge win if XBL2-based components could be more scalable than ones written in pure JavaScript using vanilla DOM calls. That way, XBL2 could enable new kinds of applications and reduce memory use of existing applications, rather than just providing convenience and bridging, as Tab seems to envision. Regards, Maciej
Re: XBL2: First Thoughts and Use Cases
On Mon, Dec 13, 2010 at 10:33 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Dec 14, 2010 at 2:46 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Then there's no problem. You don't need the templates to be live to make child changes work. You just need to maintain some record that any normal-DOM elements which match * should appear as children of the shadow node #three in the final flattened tree. appendChild()'ing new elements to the x-fancycontainer will appropriately wire the elements into the shadow tree. This sort of selector-node map can be divined from the template and copied into a separate data structure, just like the actual shadow nodes can just be cloned out of the template into separate live DOM. No linkage back to the original template is required. Sure, but you also have to handle the includes attribute and the attributes attribute, so in fact you need to know a fair bit about the template to handle dynamic changes to the bound document. You might decide it's easier to just hold a reference to the template itself. If you indeed keep using includes/locked, attributes, and pseudo from the template, you end up with a semi-live template, where modifications to those values could affect the instances. I think you'd be better off with something like this: * Each bound instance holds data on how information (attribute values, nodes, CSS pseudo-elements matching, etc.) is forwarded from the bound element down to the the shadow subtree. * During the binding phase, this information is populated by reading corresponding attributes on the template. This approach allows: * Having a clean break between templates and instances. * Allowing bound behaviors manipulate their forwarding at will, without affecting the template. Here's a mental model I would present to Web developers: * The ability to influence a shadow DOM subtree from the outside is provided by the Shadow DOM Forwarding. * It's a list (array) of rules you associate with to the shadow DOM. * Each rule specifies how a node, an attribute, a text node, current language (and possibly direction), or a CSS pseudo selector is forwarded from the bound element to the elements in the shadow subtree. * You can create this set of rules imperatively during the binding phase, or * You can use templates to wire this up declaratively. * You can modify the rules at any time while the shadow subtree exists, but changes to rules are not retroactive. * In other words, what's been forwarded is not re-forwarded or affected in any way once the forwarding rule is changed or removed. WDYT? But yeah, we're agreeing. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: XBL2: First Thoughts and Use Cases
On Mon, Dec 13, 2010 at 10:33 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Dec 14, 2010 at 2:46 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Then there's no problem. You don't need the templates to be live to make child changes work. You just need to maintain some record that any normal-DOM elements which match * should appear as children of the shadow node #three in the final flattened tree. appendChild()'ing new elements to the x-fancycontainer will appropriately wire the elements into the shadow tree. This sort of selector-node map can be divined from the template and copied into a separate data structure, just like the actual shadow nodes can just be cloned out of the template into separate live DOM. No linkage back to the original template is required. Sure, but you also have to handle the includes attribute and the attributes attribute, so in fact you need to know a fair bit about the template to handle dynamic changes to the bound document. You might decide it's easier to just hold a reference to the template itself. But yeah, we're agreeing. Begging the question. ^_^ All of the information from the template can be duplicated in appropriate data structures on the element itself, like Dimitri explains. This allows us to treat the template solely as a stamp, used only at initialization and then thrown away. This gains us a few things. For one, you now have a simpler, more static model of how things work. There's no action-at-a-distance where changes to the template late in the page lifecycle can affect elements created during the original page parse; once an element is created with the appropriate information, it stays that way forever, unless the author explicitly monkeys around with it. For two, it naturally exposes all the magical template abilities to plain javascript, allowing everything to be manipulated by script after-the-fact, or even done entirely through script if that is, for whatever reason, easier than writing a template into a page. I think this is A Good Thing(tm). In general, I don't think we shouldn't be adding new magical features to the platform without ensuring they can be handled in script as well. 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. But with the other added benefits that you get from making everything happen out in the open, I think the decision is a lot clearer. ~TJ
Re: XBL2: First Thoughts and Use Cases
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? -Boris
Re: XBL2: First Thoughts and Use Cases
On 12/14/10 11:03 AM, Tab Atkins Jr. wrote: Script should be able to walk and mutate the shadow DOM for an element I'm not sure I agree, in fact. Why should script be able to do this? Sorta supporting this has been a constant source of problems in Mozilla' XBL1 implementation, and significantly increases the complexity of correct implementations (which Mozilla's XBL1 is not). Why is this needed? -Boris
Re: XBL2: First Thoughts and Use Cases
On Tue, Dec 14, 2010 at 11:14 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/14/10 11:03 AM, Tab Atkins Jr. wrote: Script should be able to walk and mutate the shadow DOM for an element I'm not sure I agree, in fact. Why should script be able to do this? Sorta supporting this has been a constant source of problems in Mozilla' XBL1 implementation, and significantly increases the complexity of correct implementations (which Mozilla's XBL1 is not). Why is this needed? This is interesting. Can you give an example? I am wondering if you and Tab are talking about the same thing. What sorts of problems? -Boris
Re: XBL2: First Thoughts and Use Cases
On Tue, Dec 14, 2010 at 11:23 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/14/10 11:16 AM, Dimitri Glazkov wrote: This is interesting. Can you give an example? I am wondering if you and Tab are talking about the same thing. What sorts of problems? The issues we've run into is that the shadow DOM tree can get mutated, which makes the actual DOM get out of sync with the data structures that represent insertion points (what I think XBL2 calls output ports) and the like). After this, adding normal DOM children to the bound element at best puts them in the wrong place in the shadow DOM; at worst we've had exploitable crash issues we had to fix. Hmm. I'm not well-versed enough in XBL1 to understand what all the difficulties are, but what we're envisioning is pretty simple and shouldn't lead to many problems. Given a template with some output ports, it's instantiated by cloning the shadow DOM and then setting up a map of selectors-shadow-nodes to represent the output ports. If you mutate the shadow DOM without paying attention to the outputPorts map, there are three possibilities for each port: 1. It points to a shadow node that wasn't mutated. No change. 2. It points to a shadow node that was moved. Everything currently attached to that shadow node, and any new elements added to the component which match the selector, will show up wherever the shadow node was moved to. 3. It points to a shadow node that was removed. Existing normal nodes which were pointing to that shadow node now don't show up at all in the final flattened tree (they lose their attachment, unless you ask for them to be reattached). New elements that get added and which match the selector can either ignore the selector (because we know that port is invalid) or just explicitly get put nowhere in the final flattened tree. Either option would be fine with me. Now if the shadow DOM can only be mutated by the binding itself, then it's possible to just avoid those problems in the binding script or restrict the things that script can do. But if the shadow DOM is exposed to the page the bound element is in, then the implementation needs to handle arbitrary mutations _somehow_, since you can't rely on things outside the binding playing nice with the binding. Or, of course, restrict what _that_ script can do with the shadow DOM, but that has more potential for weird breakage if the binding changes out from under the scripts that are trying to poke at it. All of the cases I outlined above can be run into when you're mutating a live template as well. Are there additional cases I'm missing that you have problems with? Are they perhaps a result of having both a mutable shadow and a live template? ~TJ
Re: XBL2: First Thoughts and Use Cases
On Mon, Dec 13, 2010 at 5:12 AM, Dimitri Glazkov dglaz...@google.comwrote: We definitely have use-cases that require the shadow DOM to be dynamically updated when an element that expands to a template instance has its subtree changed. Almost every application that combines dynamic DOM modification (e.g. editing) with templates needs this. So you do need to record how instances were created. Can you give a more specific example? Suppose I use XBL2 to define fancycontainer, a container with elaborate styling that I can't do with CSS alone. Changes to the children of a fancycontainer need to be reflected in the shadow DOM tree built for fancycontainer, otherwise dynamic changes in the presence of fancycontainer are just broken. For example, adding a child to container would need to find the associated template instance and insert the child into the right place in the instance. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: XBL2: First Thoughts and Use Cases
On Mon, Dec 13, 2010 at 5:16 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Mon, Dec 13, 2010 at 5:12 AM, Dimitri Glazkov dglaz...@google.com wrote: We definitely have use-cases that require the shadow DOM to be dynamically updated when an element that expands to a template instance has its subtree changed. Almost every application that combines dynamic DOM modification (e.g. editing) with templates needs this. So you do need to record how instances were created. Can you give a more specific example? Suppose I use XBL2 to define fancycontainer, a container with elaborate styling that I can't do with CSS alone. Changes to the children of a fancycontainer need to be reflected in the shadow DOM tree built for fancycontainer, otherwise dynamic changes in the presence of fancycontainer are just broken. For example, adding a child to container would need to find the associated template instance and insert the child into the right place in the instance. Ah, you're thinking about changes to the normal DOM. We're afraid of changes to the template. Different story. To be more specific, if we assume something like the following (handwavey syntax): element name=x-fancycontainer template div id=one div id=two div id=three content selector=* /div /div /div /template /element x-fancycontainer spanfoo/span /x-fancycontainer Then there's no problem. You don't need the templates to be live to make child changes work. You just need to maintain some record that any normal-DOM elements which match * should appear as children of the shadow node #three in the final flattened tree. appendChild()'ing new elements to the x-fancycontainer will appropriately wire the elements into the shadow tree. This sort of selector-node map can be divined from the template and copied into a separate data structure, just like the actual shadow nodes can just be cloned out of the template into separate live DOM. No linkage back to the original template is required. We're just afraid of, say, attaching event handlers or data-* attributes or whatever to shadow nodes, and then having the nodes get destroyed and recreated underneath us when the template changes. An element shouldn't destroy itself unless the author explicitly tells it to. XBL does try to be careful to destroy as little as possible, but it shouldn't destroy *anything* unless explicitly requested. ~TJ
Re: XBL2: First Thoughts and Use Cases
On 12/13/10 5:46 PM, Tab Atkins Jr. wrote: Ah, you're thinking about changes to the normal DOM. We're afraid of changes to the template. I think roc explicitly said that he thinks the XBL2 spec's section on this seems ... dispensable. I agree with him, for what it's worth. -Boris
Re: XBL2: First Thoughts and Use Cases
On Mon, Dec 13, 2010 at 9:11 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/13/10 5:46 PM, Tab Atkins Jr. wrote: Ah, you're thinking about changes to the normal DOM. We're afraid of changes to the template. I think roc explicitly said that he thinks the XBL2 spec's section on this seems ... dispensable. I agree with him, for what it's worth. Then we're all in agreement. ^_^ The rules that templates set up for assigning normal DOM nodes to places in the final flattened tree should stick around somehow even if we don't retain a reference to the template itself, so that adding children to the element afterwards has the same effect as parsing them in the original HTML. ~TJ
Re: XBL2: First Thoughts and Use Cases
On Tue, Dec 14, 2010 at 2:46 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: Then there's no problem. You don't need the templates to be live to make child changes work. You just need to maintain some record that any normal-DOM elements which match * should appear as children of the shadow node #three in the final flattened tree. appendChild()'ing new elements to the x-fancycontainer will appropriately wire the elements into the shadow tree. This sort of selector-node map can be divined from the template and copied into a separate data structure, just like the actual shadow nodes can just be cloned out of the template into separate live DOM. No linkage back to the original template is required. Sure, but you also have to handle the includes attribute and the attributes attribute, so in fact you need to know a fair bit about the template to handle dynamic changes to the bound document. You might decide it's easier to just hold a reference to the template itself. But yeah, we're agreeing. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: XBL2: First Thoughts and Use Cases
On Sat, Dec 11, 2010 at 1:04 PM, Dimitri Glazkov dglaz...@google.comwrote: Looking at the use cases, I couldn't think of anything that would require this type of functionality -- at least not at the cost of its complexity and performance implications. Perhaps something simpler, forward-only would be a better solution? Maybe a template is just a stencil that provides a declarative way to describe how the shadow DOM is wired up. Once the instance is stenciled, it has no knowledge of where or how it was created. We definitely have use-cases that require the shadow DOM to be dynamically updated when an element that expands to a template instance has its subtree changed. Almost every application that combines dynamic DOM modification (e.g. editing) with templates needs this. So you do need to record how instances were created. I agree that handling dynamic updates to the bindings document is less well-motivated. It might be useful for a template editor. But a template editor could probably just unapply the entire bindings document, modify it, and reapply it. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: XBL2: First Thoughts and Use Cases
On Sun, Dec 12, 2010 at 12:52 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Sat, Dec 11, 2010 at 1:04 PM, Dimitri Glazkov dglaz...@google.com wrote: Looking at the use cases, I couldn't think of anything that would require this type of functionality -- at least not at the cost of its complexity and performance implications. Perhaps something simpler, forward-only would be a better solution? Maybe a template is just a stencil that provides a declarative way to describe how the shadow DOM is wired up. Once the instance is stenciled, it has no knowledge of where or how it was created. We definitely have use-cases that require the shadow DOM to be dynamically updated when an element that expands to a template instance has its subtree changed. Almost every application that combines dynamic DOM modification (e.g. editing) with templates needs this. So you do need to record how instances were created. Can you give a more specific example? I agree that handling dynamic updates to the bindings document is less well-motivated. It might be useful for a template editor. But a template editor could probably just unapply the entire bindings document, modify it, and reapply it. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
