RE: Interop: Floaters and BFC within inline-blocks

> 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: http://jsfiddle.net/s2pwbjcr/1/ (IE/FF/Chrome
> > agree) Next we add a non-floated div with a 2px border, this is not a
> > BFC so nothing changes: http://jsfiddle.net/b2rd8ynx/1/ (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: http://jsfiddle.net/xzt063uv/2/

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

I said "seems," and was initially thinking you were because per the 2.1 spec you're supposed to line up floats next to one another unless a new BFC is created or the width of the float content is greater than that of the containing block. If you're not creating a new BFC, then it is just that you guys don't line up all floats within the containing block before deciding where the break should be. This, as well is defined in 2.1:

 # In a block formatting context, each box's left outer edge touches the left edge of the containing block (for right-to-left formatting, right edges touch). 
 # This is true even in the presence of floats (although a box's line boxes may shrink due to the floats), unless the box establishes a new block formatting context (in which case the box itself may become narrower due to the floats).

At any rate the two cases should end up behaving the same since there is no width defined on the float. You shouldn't be breaking the floats until there is no more room within the viewport in this case.

> 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.  That
> said, I believe Gecko's heuristics for intrinsic width for content containing
> floats are not great, but I'm hesitant to change them without knowing that
> such changes will help move browsers together.  If you have a proposal for
> how to define the intrinsic widths of content containing floats, in a way that
> doesn't involve doing layout, and that you've shown are compatible with
> Web content to the extent that you're shipping IE with them, I'd be
> extremely interested in seeing those proposals.

I understand your hesitancy but as Morten said, Blink and Gecko should be using Layout to make these decisions as it achieves the _correct_ result per the spec. We currently do this and do not receive a significant perf regression as a result. At any rate, here is a screenshot of the problem this creates for us: http://imgur.com/gABKr1h


> I believe the working group did agree at one point that we would accept
> intrinsic width behavior for floats being suboptimal in order to have a
> definable behavior for intrinsic widths.  In other words, it has to involve
> either layout or heuristics, and doing it by doing layout was hard to
> implement and bad for performance, so we'd have heuristics.
> 
> -David

Please let me know if you have any other questions regarding our implementation or hesitancies for Gecko matching that. Thank you for your response.

Greg

Received on Friday, 3 October 2014 15:51:44 UTC