- From: David Hyatt <hyatt@apple.com>
- Date: Tue, 03 Feb 2009 14:58:36 -0600
- To: Anton Prowse <prowse@moonhenge.net>
- Cc: www-style@w3.org
On Feb 3, 2009, at 2:15 PM, Anton Prowse wrote: > > David Hyatt wrote: >> On Feb 2, 2009, at 2:55 PM, Anton Prowse wrote: >>> Note however that if the preceding floats even partly intersect >>> the content area of the containing block of the new float, all the >>> rules /are/ applied in all browsers mentioned except Safari which >>> applies all the float rules but not the BFC rule. (And except IE7, >>> which cannot allow the containing block to overlap the preceding >>> floats due to its hasLayout model.) >>> >> Can you show me a test case? This may be fixed in the latest >> WebKit, but I want to make sure. > > Sure: > > http://dev.moonhenge.net/css21/test-cases/block-formatting-contexts/bfc-in-containing-block-next-to-intruding-float--left.html > > http://dev.moonhenge.net/css21/test-cases/block-formatting-contexts/bfc-in-containing-block-next-to-intruding-float--right.html > > These are merely modifications of your own test cases. > Correction: these were David Baron's tests. Yes, we do still fail these tests even in the latest WebKit, assuming that the consensus is that the overflow block should attempt to avoid intruding floats. Really this all seems somewhat arbitrary to me. If we weren't concerned with compatibility, I'd actually prefer matching what is currently in the CSS2.1 spec. Is that not an option? It just looks like a bug to me that the overflow section should ever be allowed to overlap the float (regardless of whether the preceding floats intrude into the following block's box or not). dave (hyatt@apple.com)
Received on Tuesday, 3 February 2009 20:59:22 UTC