Re: [XBL] content element and locked

[Cyril Concolato]

Hi Ian, Ian Hickson a écrit : On Fri, 12 Jan 2007, Cyril Concolato wrote: [the example in section "4.5. The Final Flattened Tree"] There are two bound elements in that example. One is inside the other's shadow tree. What would you final flattened tree look like if you didn't assign the element to a <content> element in both shadow trees? In this particular example, the flattened tree (btw, why do you call it final ?) wouldn't be different since the second content assigned to C is not part of it. It's the "final" flattened tree because it's what gets rendered after everything gets processed. Hence, final. I think final is superfluous since the specification does not mention 'intermediate' flattened tree, but that's a minor point. I don't really understand what you mean. "C" is part of the final tree. <content> elements never are part of the final flattened tree. If "C" wasn't assigned to a <content> element in the nested binding, I don't understand how it could be part of the flattened tree at all. I understand that <content> element are not part of the flattened tree. I was unclear. What I meant was that final flattened tree wouldn't be affected by C not being assigned to the first <content> element (the one that is a DOM parent of R). What is the answer to the question: In the example, if the binding on Q is removed, one would have to redistribute the nodes for the binding of B ? Nope, the binding on Q doesn't affect B's binding's shadow tree. Again I was unclear sorry. I meant when you remove the binding on Q, the flattened tree changes. My understanding was that you had to rebuild it, in particular by redistributing the children of B. I think the answer is yes, that's why when applying the binding for Q, one can safely unassign C (i.e. unassign the content element parent of R) because the redistribution of the nodes for the binding of B will reassign the content that was unassigned. I don't really follow this. What I'm realizing (and what you're probably saying) is that since C is assigned to two content elements, once the binding on Q is removed, you remove one assignement on C and you end up in the same state as if the binding on Q had never existed, so you do not need to redistribute the children of B. Is this correct ? Is this is correct, you don't have to store multiple content elements per Node ? Exactly how you implement it is an implementation detail. You don't necessarily have to *store* the assignment, since you can derive it (there's no way C could be assigned to the second <content> element in the first shadow tree if it's assigned to a <content> element in the second shadow tree). But conceptually it's still assigned to both. HTH, It did help. Thanks, Cyril