W3C home > Mailing lists > Public > www-style@w3.org > January 2012

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

From: Alan Gresley <alan@css-class.com>
Date: Tue, 31 Jan 2012 13:03:47 +1100
Message-ID: <4F274C03.3000404@css-class.com>
To: Rossen Atanassov <Rossen.Atanassov@microsoft.com>
CC: Morten Stenshorne <mstensho@opera.com>, fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
On 31/01/2012 12:29 PM, Rossen Atanassov wrote:
>> -----Original Message----- From: Alan Gresley
>> [mailto:alan@css-class.com] Sent: Monday, January 30, 2012 3:59 PM
>> The spec's reference to 'space' is a visual 'width' between the
>> left float (magenta) and<div>  container. It doesn't matter what
>> the computed and used height of the BFC table is. There is nothing
>> in the spec that says that the BFC table should clear the left
>> float (blue).
> Hello Alan,
> I am still not sure why you insist on an interpretation of 'space' as
> 'width' - can you point me to a specific line in the 2.1 spec?

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].

   | If 'width' is computed as 'auto', the used value
   | is the "shrink-to-fit" width.


   | 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.

Maybe the part of the spec for 'bfc-next-to-float' in 9.5 [3] should be 

   | 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 am also not sure why you would insist or expect the BFC in your
> previous example (the auto-height table) to behave different than a
> single character that is taller than the float?

I not expecting it to render different.

> Here's a modified version of your example.
> <!DOCTYPE html>
> <style>
>     div { width: 190px; border: solid thick silver; }
>     p   { width: 100px; height: 100px;
>           border: dashed; background: yellow; margin: 0; }
>     #a { color: magenta; float: left; }
>     #b { color: blue;    float: right; }
> </style>
> <div>
> <p id=a>FLOAT LEFT</p>
> <p id=b>FLOAT RIGHT</p>
> <span style="font-size: 120px">|</span>
> </div>
> Thanks, Rossen

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.

<!DOCTYPE html>
    div { width: 190px; border: solid thick silver; font-size: 160px;}
    p   { width: 100px; height: 100px;
          border: dashed; background: yellow; margin: 0; }
    #a { color: magenta; float: left; font-size: 0.1em}
    #b { color: blue;    float: right; font-size: 0.1em}

<p id=a>FLOAT LEFT</p>
<p id=b>FLOAT RIGHT</p>

1. http://www.w3.org/TR/2011/REC-CSS2-20110607/tables.html#table-display
2. http://www.w3.org/TR/2011/REC-CSS2-20110607/visudet.html#float-width
3. http://www.w3.org/TR/CSS21/visuren.html#bfc-next-to-float

Alan Gresley
Received on Tuesday, 31 January 2012 02:04:20 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:09 UTC