[reflow branch] Blocks with new block formatting context are to wide when adjacent to floats




11 years ago
11 years ago


(Reporter: philippe (part-time), Unassigned)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [ComputeSize aAvailableWidth])


(2 attachments)



11 years ago
Blocks that establish a new block formatting context (overflow:hidden, table) are to wide when preceded by a floated block. The width is incorrectly computed to the width of the parent block.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20061102 Minefield/3.0a1

Comment 1

11 years ago
Created attachment 244388 [details]
test case
Yeah....  We should probably either change the computed width of those blocks/tables based on what floats are currently on the line or change the block-placement code to just clear them past the floats...
Ever confirmed: true
OS: Mac OS X 10.4 → All
Hardware: Macintosh → All
According to the spec, the latter.
So basically in nsBlockFrame::ReflowBlockFrame once we construct the child's reflow state if the mComputedWidth + mComputedBorderPadding + mComputedMargin is bigger than the availSpace.width we should try clearing past floats?  At least in cases wheh the child block is a block formatting context?
We might need to be careful with auto margins, though.  But basically, yes, since CSS2.1 says (in 9.5):

The margin box of a table, a block-level replaced element, or an element in the normal flow that establishes a new block formatting context (such as an element with 'overflow' other than 'visible') must not overlap any floats in the same block formatting context as the element itself. 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. 

Comment 6

11 years ago
(In reply to comment #3)
> According to the spec, the latter.
The blocks in the testcase have an auto width. Behaviour in current trunk builds, Gecko 1.8.1, and all other browsers (Safari, Webkit nightly builds, Opera, IE Mac, IE 6 and 7 Windows, Konqueror 3.5.4, iCab 3.0) is to account for the width of the floated block when computing the width of the block that establish a new block formatting context. This is also how I understand 9.4.1 in CSS 2.1.
(Most browsers, except Gecko and iCab, handle the margins incorrectly, but that is not the point of this bug).

Does that mean that this behaviour is wrong ?

If those blocks have a declared width, and there is not enough space next to the float, then yes, they should drop below (clear) the floated block. Gecko (non reflow) has some bugs on this, like bug 350474).


Comment 7

11 years ago
Created attachment 244518 [details]
Screenshot of test case in WebKit

This is how current WebKit build handles the test case. Not the incorrect horizontal margin handling between the 2 blocks. The computed width of the element next to the float is correct, however.


11 years ago
Attachment #244518 - Attachment mime type: text/html → image/png
So... I dunno about the table case, but CSS2.1 section 10.3.3 applies to the overflow:hidden case.  Per that part of the spec, the block's width should not depend on whether it's overflow property is set to hidden or not.  It's not clear how 9.4.1 is supposed to interact with this.

I'll raise it with the CSS WG, I guess.
Whiteboard: [ComputeSize aAvailableWidth]
Fixed on reflow branch.
Last Resolved: 11 years ago
Resolution: --- → FIXED


11 years ago
You need to log in before you can comment on or make changes to this bug.