Bug 22764 – bottom border misaligned due to image

• Component: New Bugs
• Status: RESOLVED INVALID

[jasneet]

I Steps:
Go to http://www.googlelunarxprize.org/

II Issue:
In right and left columns, the bottom border below rss feed subscribe is misaligned.

III Conclusion:
If we remove feed image before text "Subscribe", then it works fine in webkit

IV Other Browsers:
IE7: ok
FF3: ok

V Nightly tested: 39088

Bug in Chromium : http://code.google.com/p/chromium/issues/detail?id=1438

[jasneet]

Created attachment 25898 [details]
reduced testcase

[Eric Seidel (no email)]

Our display of the test case matches Firefox.  Are we sure this a bug?

[Dave Hyatt]

This doesn't look like a valid bug to me.

[Eric Seidel (no email)]

Our current behavior matches FF4, so clearly they've changed their behavior away from FF3.

Line height measurement is documented here:
http://www.w3.org/TR/CSS2/visudet.html#line-height

Hmmm... This section also seems relevant:

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 the margin box of 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.
http://www.w3.org/TR/CSS2/visuren.html#floats

[Eric Seidel (no email)]

It looks like the float overflows the <div> (which seems to be expected, but I haven't found the relevante CSS 2.1 text yet), but the <table> has an implicit clear on it.  Meaning the table is pushed down below the float, causing the gap in the border.

In general comparing with IE (especially in strict mode) is folly.  IE's rendering has historically been horribly non-standards compliant.  They were the standard for years and years, but that is no longer the case.

[Eric Seidel (no email)]

"Since a float is not in the flow, non-positioned block boxes created before and after the float box flow vertically as if the float did not exist. However, the current and subsequent line boxes created next to the float are shortened as necessary to make room for the margin box of the float."

Maybe be the relevant line of CSS 2.1 to explain that floats can overflow out of their containing blocks.

I think basically floats don't create line boxes, so they don't get included in block height calculations, thus blocks colapse to fit their lines, while floats may yet overflow those blocks.

This test case is invalid as far as I can tell.  IE's behavior is wrong.

[Eric Seidel (no email)]

This IE quirk is in fact explicitly mentioned in "on having layout" (a great read if you ever want to write a site which works in IE!):
http://www.satzansatz.de/cssd/onhavinglayout.html#clear

"Floats are auto-contained by layout elements. That's one reason why most beginners struggle with their IE-build pages in a compliant browser where floats stick out of the container when not cleared."

Basically IE auto-clears floats and CSS 2.1 says not to.

[Mustafizur Rahaman (rahaman)]

(In reply to comment #6)
> "Since a float is not in the flow, non-positioned block boxes created before and after the float box flow vertically as if the float did not exist. However, the current and subsequent line boxes created next to the float are shortened as necessary to make room for the margin box of the float."
> 
> Maybe be the relevant line of CSS 2.1 to explain that floats can overflow out of their containing blocks.
> 
> I think basically floats don't create line boxes, so they don't get included in block height calculations, thus blocks colapse to fit their lines, while floats may yet overflow those blocks.
> 
> This test case is invalid as far as I can tell.  IE's behavior is wrong.

Hi Eric,

I might be wrong, but based on my investigation, I have found that floats create their own line boxes (in RenderBlock::LineBreaker::skipLeadingWhitespace, therefore they call positionNewFloatOnLine from here). But inside positionNewFloatOnLine(), I did not find any code to update block height. This could be the right behavior, but this is what I saw in the code