Re: [XBL] content element and locked

On 1/9/07, Cyril Concolato <cyril.concolato@enst.fr> wrote:
>
> After a second reading of the specification, I understand that now better
> the processing of content elements. I made a diagram of the algorithm. I
> attach it in case you find it useful and right. I had a hard time
> understanding what you meant by "next most derived" in step 6. I think you
> mean "the parent binding in the binding chain". If so, could you use my
> wording or another explicit wording instead.

I've now explicitly defined the term "next most derived".


> From this diagram, I understood a bit more the 'locked' attribute. I
> understand that a node may be assigned to multiple content elements. But, am
> I correct to say that if a node is assigned a locked content, it cannot have
> another content assigned (locked or not).

The "locked" attribute has no bearing on being assigned to multple
<content> elements. Each explicit child can only be assigned to a
single <content> element per shadow tree. It's just that in certain
edge cases (namely when the parent of a <content> element is itself
bound), it is possible for an explicit child to be taking part in two
separate shadow trees nested one in the other, and then it is assigned
to two <content> elements. See the example in section "4.5. The Final
Flattened Tree".


> Some points remain unclear. I'm still not 100% sure about when the
> assignment of a content element to a node is removed. Do you remove all
> assignments when you redistribute nodes? I don't think so, otherwise Step 1
> would never be applied. But on the other hand, if a node is assigned to a
> unlocked content element, each time the nodes are redistributed, a new
> assignment may happen. Thus the number of content assigned to a node could
> increase indefinitely. Could you clarify?

I've tried to clarify this. Let me know if that's better.

-- 
Ian Hickson

Received on Tuesday, 9 January 2007 21:12:59 UTC