Re: [CSS21] display:run-in clarifications

Bert Bos wrote:
> If the child is floating, item 2 applies, which says: "[...] the 
> containing block is formed by the content edge of the nearest 
> block-level, table cell or inline-block ancestor box."

Indeed.

> Although the text doesn't say so explicitly, it seems reasonable to 
> assume that "part of the time" refers to the cases where the 'run-in' 
> is displayed as a block and not to the cases where the run-in is 
> displayed inline.

Agreed.

> In other words, an element that is displayed run-in 
> is *not* the containing block for its floating child. The containing 
> block must instead be found among the ancestors of the run-in element.

The element, or the box?  That's the real question here.  The text is 
talking about ancestor boxes; I don't know what assumptions, if any, it 
makes about ancestor elements.  In particular, in this case we have an 
ancestor box that does not correspond to an ancestor element

The real problem here, I think, is that there are two separate trees 
here (DOM tree and box tree) and they being are used 
semi-interchangeably.  That doesn't work well, because they can be 
pretty different, especially in cases like run-in.

> If the child is absolutely positioned, the definition is more direct. 
> Item 4 in 10.1 applies and it says to look for an ancestor with a 
> certain 'position' property and then defines the containing block both 
> for inline ancestors and others.

Here the text does seem somewhat more unambiguously talking about 
elements, though in part 2 of item 4 it's talking about the padding edge 
of the ancestor, which only makes sense for boxes...

> Is it better that the containing block of a floating child is formed by 
> the block after the run-in, or by that block's parent?

That's the question, yes.

> I interpret 10.1 as using the latter. There is a difference, of course, but is it an 
> important difference? It has an influence on how much left/right margin 
> a designer must give the float.

It's an important difference from the point of view of at least the 
Gecko implementation.  Determining the containing block solely from the 
box tree is preferable in our implementation, especially because in some 
cases it's the only way to get the right behavior (e.g. for floats 
contained between two block kids of an inline or that are kids of a 
table-row the containing block is an anonymous box, not an actual DOM 
element).  Right now all containing block determination is done on the 
box tree in Gecko.

-Boris

Received on Tuesday, 1 September 2009 16:28:19 UTC