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

Alan Gresley <alan@css-class.com> writes:

> On 26/01/2012 8:23 PM, Morten Stenshorne wrote:
>> fantasai<fantasai.lists@inkedblade.net>  writes:
>>
>>> Dear Layout Engineers,
>>>
>>> http://lists.w3.org/Archives/Public/www-archive/2012Jan/att-0035/foo.html
>>>
>>> Really?
>>>
>>> <style>
>>>    #a { float: left; }
>>>    #b { float: right; }
>>>    p  { width: 100px; height: 100px; }
>>>    div { width: 190px; }
>>> </style>
>>>
>>> <div>
>>> <p id=a>FLOAT LEFT</p>
>>> <p id=b>FLOAT RIGHT</p>
>>> <table><tr><td>table table table table table table table table</table>
>>> </div>
>>>
>>> +------------------------+
>>> |+------------+ +-------+|
>>> || FLOAT LEFT | | table ||
>>> ||            | | table ||
>>> |+------------+ | table ||
>>> |          +------------+|
>>> |          |FLOAT RaGlT ||
>>> |          |      table ||
>>> |          +------------+|
>>> |               | table ||
>>> |               +-------+|
>>> +------------------------+
>>
>> Nice! All the browsers are bug-compatible, except IE10, which gets it
>> right instead.
>
>> Narrowing the BFC isn't really necessary, BTW. You see the same bug
>> with:
>
>> It gets too tall to fit above the yellow float (or beside the blue
>> float, if you like), so it should be moved down, beside the yellow
>> float. But that increases the available width (which, if properly laid
>> out again, also should reduce its used height by a lot).
>>
>> Determining the position (and layout) of the BFC block without taking
>> its used height into consideration is a mistake when we want to satisfy
>> http://www.w3.org/TR/CSS21/visuren.html#bfc-next-to-float .
>>
>> This issue is already filed in Opera's BTS, BTW.
>
>
> This rule does not apply. If a BFC can fit beside the first float,
> then it will flow beside it. Read this part of the spec.
>
>   | 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*.
>
> There is *sufficient space* for the BFC in your two test case as well
> as the examples in this test case.

I see that there has been some discussion in this thread regarding the
meaning of "space". I believe space is two-dimensional in this context,
but I don't think it matters that much here.

Spec quote, part 1:

    "The border box of a table, a block-level replaced element, or an
    element in the normal flow that establishes a new block formatting
    context (such as an element with 'overflow' other than 'visible')
    must not overlap the margin box of any floats in the same block
    formatting context as the element itself."

Spec quote, part 2:

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

I don't see why anything in part 2 should invalidate what part 1
says. My interpretaion remains that under no circumstances should the
border box of a table (...)  overlap the margin box of any floats in the
same block formatting context.

They clearly do overlap in e.g. Opera.

Hence, I believe IE is more correct than the others.

-- 
---- Morten Stenshorne, developer, Opera Software ASA ----
---- Office: +47 23693206 ---- Cellular: +47 93440112 ----
------------------ http://www.opera.com/ -----------------

Received on Wednesday, 1 February 2012 13:40:07 UTC