RE: [CSS21] BFC may become narrower and collide with a previous float

> -----Original Message-----
> From: Alan Gresley [mailto:alan@css-class.com]
> Sent: Monday, January 30, 2012 6:04 PM
> 
> Hello Rossen,
> 
> Please see 17.2 [1].
> 
>    | table (In HTML: TABLE)
>    |  Specifies that an element defines a block-level
>    |  table: it is a rectangular block that participates
>    |  in a block formatting context.
> 
> This rectangular block has a *shrink-to-fit* algorithm which is similar to that
> of a float. Please see 10.3.5 [2].
> 

Correct.

>    | If 'width' is computed as 'auto', the used value
>    | is the "shrink-to-fit" width.
> 
>       (and)
> 
>    | Calculation of the shrink-to-fit width is similar
>    | to calculating the width of a table cell using the
>    | automatic table layout algorithm.
> 
> Note the word *width* in the above spec.
> 

This is simply explaining how used width and in particular STF works for tables. Once the width is computed it is the input for the layout algorithm computing the used height of the table. And once this is done, you have a rectangle (the border box) that can be used for space intersection tests (space in this case implies 2D not 1D, i.e. width & height not only width).

> Maybe the part of the spec for 'bfc-next-to-float' in 9.5 [3] should be
> changed.
> 
>    | If necessary, implementations should clear the said
>    | element by placing it below any preceding floats,
>    | but may place it adjacent to such floats if there is
>    | *sufficient space*.
> 
> s/sufficient space/sufficient available width

I wouldn't change that - again, the term space here implies 2D not 1D which is what I have implemented in IE and it sounds like David is getting it implemented in their code (Opera also has a bug apparently).

> The above test, uses a span. This would be the same if it was an anonymous
> block box (see code below). Any test that has two floats that causes the later
> float to drop below the earlier float can cause a situation where in-flow
> content after all floats can sit beside the first float and cause visual
> overlap/underlap of later floats.
> 

Not true actually. Inline content or BFC boxes (which floats are) should not intersect (overlap). 

Anyway, I still don't see anything that needs changed with the spec so far. I will let other implementers comment if they think differently.

Thanks,
Rossen

Received on Tuesday, 31 January 2012 04:25:39 UTC