Bug 48396 - Siblings of floated elements should be cleared below the float if they are too wide to fit in the containing block.
Summary: Siblings of floated elements should be cleared below the float if they are to...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Other OS X 10.5
: P2 Normal
Assignee: Andy Estes
URL:
Keywords: HasReduction, InRadar
Depends on:
Blocks:
 
Reported: 2010-10-26 21:38 PDT by Andy Estes
Modified: 2010-10-27 01:21 PDT (History)
3 users (show)

See Also:


Attachments
Reduction (355 bytes, text/html)
2010-10-26 21:43 PDT, Andy Estes
no flags Details
Patch (29.73 KB, patch)
2010-10-26 22:05 PDT, Andy Estes
hyatt: review+
Details | Formatted Diff | Diff
Patch (30.02 KB, patch)
2010-10-26 22:20 PDT, Andy Estes
aestes: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andy Estes 2010-10-26 21:38:44 PDT
Siblings of floated elements should be cleared below the float if they are too wide to fit in the containing block.
Comment 1 Andy Estes 2010-10-26 21:40:00 PDT
<rdar://problem/7699849>
Comment 2 Andy Estes 2010-10-26 21:43:10 PDT
Created attachment 71980 [details]
Reduction
Comment 3 Andy Estes 2010-10-26 21:56:35 PDT
CSS 2.1 says in section 9.5:

"The border 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. They may even make the border box of said element narrower than defined by section 10.3.3. CSS2 does not define when a UA may put said element next to the float or by how much said element may become narrower."

WebKit does not clear elements adjacent to floats if they are wider than the containing block, instead keeping them on the same line and allowing them to spill out the right side of the containing block. We should match the spec in this regard and clear the element below the float even if it is too wide for the containing block. This seems to also match IE's and Firefox's behavior.
Comment 4 Andy Estes 2010-10-26 22:05:57 PDT
Created attachment 71982 [details]
Patch
Comment 5 Andy Estes 2010-10-26 22:20:31 PDT
Created attachment 71984 [details]
Patch
Comment 6 Simon Fraser (smfr) 2010-10-26 22:25:39 PDT
Comment on attachment 71984 [details]
Patch

It would be good to run through some CSS 2.1 testcases to see if we pass any more of them with this change.
Comment 7 Andy Estes 2010-10-26 22:26:07 PDT
(In reply to comment #6)
> (From update of attachment 71984 [details])
> It would be good to run through some CSS 2.1 testcases to see if we pass any more of them with this change.

I'd be happy to.
Comment 8 Andy Estes 2010-10-26 23:08:26 PDT
Comment on attachment 71984 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=71984&action=review

> WebCore/rendering/RenderBlock.cpp:4046
> +            if (widthAtY == availableLogicalWidth())

This was a bad idea. availableLogicalWidth() only needs to be called once in this function.
Comment 9 Andy Estes 2010-10-26 23:08:54 PDT
Comment on attachment 71982 [details]
Patch

The first patch should be the one reviewed after all.
Comment 10 Dave Hyatt 2010-10-27 00:16:20 PDT
Comment on attachment 71982 [details]
Patch

r=me, but should probably remove the "Jeffrey Zeldman" stuff from the title element in the test case.
Comment 11 Andy Estes 2010-10-27 01:19:08 PDT
Committed r70619: <http://trac.webkit.org/changeset/70619>
Comment 12 Andy Estes 2010-10-27 01:21:00 PDT
(In reply to comment #10)
> (From update of attachment 71982 [details])
> r=me, but should probably remove the "Jeffrey Zeldman" stuff from the title element in the test case.

Thanks Dave! I had actually made that change to the test, but the patch looks weird when you svn mv a file then make changes to it.