Re: [XBL] content element and locked

[Cyril Concolato]

Hi Ian, Thanks for all the changes, I think the section about inheritance are really good now. Ian Hickson a écrit : So do I understand correctly from the algorithm that a Node can be assigned to a locked content only using the xblSetInsertionPoint method ? That's one way; the other way is by it being assigned before the element is locked, and locking the insertion point dynamically. Of course, thanks. [the example in section "4.5. The Final Flattened Tree"] I see from that example that there are 2 'content' elements marked with a *, meaning that C is assigned to both content elements. I don't see the use for this possibility to assign a node to multiple content elements, since in the end, a Node can appear only once in the final flatten tree (is that correct?). If there is no use, I don't see the point of mentioning it, it is quite confusing and I would remove the '*' on content*/R. It's not that there is a use or not. It just happens when you have nested bindings. 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. 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 ? 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. Is this is correct, you don't have to store multiple content elements per Node ? Thanks for the clarification. It's better. I think it would be clearer if a Node could be assigned to, at most, one content element in the binding implicit inheritance chain. This is already the case. It can only be assigend to two <content> elements when there are two totally separate bound elements, each with their own implicit binding chain, both of which have the node as their explicit child (which, again, can only occur if the second binding is on one of the elements in the first binding's shadow tree, and that bound element has as its child node a <content> element from the outer binding's shadow tree). I understand that, sorry for the confusion. Cyril