- From: Greg Whitworth <gwhit@microsoft.com>
- Date: Fri, 3 Oct 2014 02:48:42 +0000
- To: "www-style@w3.org" <www-style@w3.org>, Morten Stenshorne <mstensho@opera.com>, Boris Zbarsky <bzbarsky@mit.edu>, Alan Stearns <stearns@adobe.com>, Bogdan Brinza <bbrinza@microsoft.com>
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/
This does not make sense as that box should not be promoted to a BFC since it is _NOT_ a
*float
*absolutely positioned element
*or a block container
per the 9.4.1 of the 2.1 spec [1] on what should create a BFC:
# Floats, absolutely positioned elements, block containers (such as inline-blocks, table-cells, and table-captions) that are not block boxes, and block boxes with 'overflow'
# other than 'visible' (except when that value has been propagated to the viewport) establish new block formatting contexts for their contents.
I would love to get feedback from the WG, especially team members on Blink/Gecko regarding this issue. We continue to receive "bugs" and outreach from authors regarding this interop issue.
Thank you,
Greg
[1] http://dev.w3.org/csswg/css2/visuren.html#block-formatting
Received on Friday, 3 October 2014 02:49:12 UTC