Re: Interop: Floaters and BFC within inline-blocks

"L. David Baron" <> writes:

> On Friday 2014-10-03 02:48 +0000, Greg Whitworth wrote:
>> I'm reviving this thread as we are wanting to get to the bottom of this interop issue regarding floats in a shrink to fit box. I'm going to start off with a simple example showing the default of how these work and then when it falls apart and creates and interop issue.
>> Starting off simple: (IE/FF/Chrome agree)
>> Next we add a non-floated div with a 2px border, this is not a BFC so nothing changes: (IE/FF/Chrome agree)
>> Now we add an additional floater before our 2px bordered div and this is where FF/Chrome seem to promote that 2px div to a BFC and IE does not:
> I don't see why you think something has become a BFC.  I'm also not
> sure what the behavior difference you're pointing out is, since it's
> hard for me to run IE.  Could you post screenshots?

You could also try a Presto-based version of Opera (12.x), which is
available on Linux (if that's what you're using):

Its behavior is very similar to IE's when it comes to shrink-to-fit.

> As far as intrinsic width calculation behavior for content
> containing floats:  I don't think Gecko's behavior is great, but
> it's the downside of having an intrinsic width behavior that can be
> calculated without doing layout.

Same in Blink -- no layout involved for intrinsic width
calculation. Presto does intrinsic width calculation as part of layout
(which, more often than not, gives you two layout passes). But I'm
pretty sure that it would be possible to get Gecko / Blink to behave
better, still without doing layout. I suppose we'd need to introduce
some sort of "preferred minimum height", to be able to tell what goes
beside floats and what goes below, given an infinite available width.

---- Morten Stenshorne, developer, Opera Software ASA ----
------------------ -----------------

Received on Friday, 3 October 2014 08:13:22 UTC