W3C home > Mailing lists > Public > www-style@w3.org > August 2014

Re: Interop: Floaters and BFC within inline-blocks

From: Morten Stenshorne <mstensho@opera.com>
Date: Fri, 29 Aug 2014 07:52:27 +0200
To: Bogdan Brinza <bbrinza@microsoft.com>
Cc: "www-style\@w3.org" <www-style@w3.org>
Message-ID: <87fvgfdeqs.fsf@aeneas.oslo.osa>
Bogdan Brinza <bbrinza@microsoft.com> writes:

> We've been fixing live site bug in IE 11 - when there's a
> shrink-to-fit container (like an inline-block) that contains a floater
> followed by a non-floater, they should be stacked vertically:
> http://jsfiddle.net/qdboet20/5/ (works in Chrome, Firefox, IE11 has a
> bug we're fixing)

I think IE11 is already doing this right (so there's no need for
fixing), while the others are wrong (except Presto). Why make the outer
shrink-to-fit container too narrow to contain both boxes beside each
other?

Disclaimer: I'm on Linux, so I cannot test IE right now, but I've tested
this quite a lot (in slightly older) IE versions (mostly 9, I think)
previously, and it has always struck me that the shrink-to-fit
implementation in IE is fantastic!

But as others have pointed out, the spec doesn't define this fully.

> While working on the fix, Kurt, our developer, has found a difference
> in behavior between other browsers:
> http://jsfiddle.net/kurt_catti_schmidt/u756q75q/ (with the fix - IE
> would match Chrome, but not Firefox)
>
> Here is what the spec
> (http://www.w3.org/TR/CSS2/visuren.html#bfc-next-to-float) says here:
> "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 think the clue here is "sufficient space", and that's up to the
shrink-to-fit algorithm to provide. Why not just provide sufficient
space? :) Like Blink does in this case. I think Blink renders this
correctly, but it's inconsistent behavior, since it breaks content in
the first test case.

All the spec has to say on the shrink-to-fit matter can be found here, I
think: http://www.w3.org/TR/CSS2/visudet.html#float-width

It essentially only talks about avoiding implicit line breaks, and
doesn't say anything about lines or other content next to floats, but in
my mind, "preferred width" should be the width that's just enough to
avoid all kind of breaks, including pushing stuff below floats.

To prove my point:

   <div style="display:inline-block;">
       <div style="float:left; width:30px; height:30px; background:yellow;"></div>
       <div>This text should be on one and the same line.</div>
   </div>

This fails in Blink and Gecko. The line gets broken. The reason is that
the "preferred width" becomes the width of the text, as an attempt to
avoid implicit breaks, but that's not going to work, since there really
needs to be room for the float beside it as well.

For further amusement, remove the DIV around the line of text (but keep
the text). Then it passes in both Blink and Gecko. What's up with that?

So this is why I think that floats must be taken into account when
calculating "preferred width" in the shrink-to-fit algorithm. IE and
Presto get this right. Blink and Gecko don't. It's the live site (and
Blink and Gecko) that should be fixed.

-- 
---- Morten Stenshorne, developer, Opera Software ASA ----
------------------ http://www.opera.com/ -----------------
Received on Friday, 29 August 2014 05:52:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:45 UTC