Bug 18250 – overlapping of text and image due to float:right

• Component: CSS
• Status: RESOLVED INVALID

[jasneet]

I Steps:
Go to 
https://www.homedepot.ca/webapp/wcs/stores/servlet/AuctionHomeView?langId=-15&krypto=oTJa5EwIaYnwBXs42YJAe%2F61ZihlDu5w8Qj04zczYEtWQAU7x8BD5N4htPFd9Gp64SayyWwASYKG%0D%0A8VJQiFW%2Fog%3D%3D

II Issue:
In the right column: under button "Place Bid", there is an overlap of "REFRESH" and image "tell a friend"

III Conclusion:
#tellAFriend { float:right;} is causing the issue. removing float:right resolves the issue.

IV Other browsers:
IE7: ok
FF3: not ok
Opera9.24: not ok

V Nightly tested: 31386

[jasneet]

Created attachment 20264 [details]
screenshot

[jasneet]

Created attachment 20265 [details]
reduction

[Just Me]

Created attachment 23187 [details]
simpler testcase

Confirmed on Chrome. This is an annoying bug that occurs frequently on Wikipedia, see e.g. http://en.wikipedia.org/w/index.php?title=Portal:Current_events/Science_and_technology&oldid=235956298

You don't need any images or fancy positioning like in your testcase, so I attached a simpler testcase I originally made for Gecko ( https://bugzilla.mozilla.org/show_bug.cgi?id=338526#c8 ).

IE7 renders it fine, but both Firefox and Google Chrome fail. The bug is being ignored by the Gecko people, hopefully it will get a better response here...

[Dave Hyatt]

Yeah.  The bug is basically that we only sample at the "top" of a line when looking for floats that affect a line.  We do this since we don't really know how tall the line is going to be until we actually put stuff on it.  It would be reasonable to do multiple samples (e.g., the top, middle and bottom of a hypothetical line based off the font of the block).

[Dave Hyatt]

I take it back.  The test case is something different I think.

[Just Me]

Thanks for looking into it. Also, this looks like a duplicate of https://bugs.webkit.org/show_bug.cgi?id=15956 and https://bugs.webkit.org/show_bug.cgi?id=13698 .

[Dave Hyatt]

What I said is still basically true.  For objects that shrink to avoid floats (like tables or overflow sections), we only sample the top of the line.

int RenderBox::containingBlockWidth() const
{
    RenderBlock* cb = containingBlock();
    if (!cb)
        return 0;
    if (shrinkToAvoidFloats())
        return cb->lineWidth(m_y);
    return cb->availableWidth();
}

A fix would involve special casing fixed height objects.  Basically because you know the height can't change if you vary the width, you can safely test for floats that intersect from your y-position to your y-position + height.

However for auto height objects you can't do that and can really only sample at your y-position.

The question is whether it would be worth making fixed height objects inconsistent with auto height objects.

CSS2.1 says:

http://www.w3.org/TR/CSS21/visuren.html#bfc-next-to-float

"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."

[Dave Hyatt]

The term "must not" is used in that paragraph, meaning this is definitely a bug.

[Dave Hyatt]

Ok as interesting as all my comments were, none of the later stuff has anything to do with the original reported bug (an overlap of float and a positioned element).  This rendering (see the first reduction) is correct and has nothing to do with wikipedia bugs.

Feel free to attach your test case to the actual wikipedia bug.

[Just Me]

Attached it to Bug 15956. Sorry for the misidentification.