If you go to http://www.giveawayoftheday.com/ in ToT or release Webkit, the image for "Giveaway of the Day" (http://www.giveawayoftheday.com/img/ga-logo-text.gif) seems to overlap the current story. I'm not sure if this is the correct behaviour or not.
Created attachment 14237 [details] Reduction Firefox puts the two outer floats (blue and red) side by side on the same line in the first case, maybe because it knows that the two inner floats (green and blue) won't fit side by side even on a separate line (contrast with the second case).
Opera is with Firefox on this.
Created attachment 14249 [details] Reduction on IE7 for VIsta This reduction looks different on IE7, attached is a screenshot. Also, the actual website (giveawayaday) looks fine in IE7 on Vista and does not show the problems Safari has.
Comment on attachment 14249 [details] Reduction on IE7 for VIsta This is sort of invalid because I didn't specify border width in the reduction and IE7 has a different default.
Created attachment 14250 [details] Reduction Specified border widths. Can you attach a screenshot of IE7's rendering of this?
Created attachment 14251 [details] Screenshot of new reduction on Vista
Firefox nightly (Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a4pre) Gecko/20070421 Minefield/3.0a4pre) agrees with WebKit on the reduction and on the URL.
Comment on attachment 14251 [details] Screenshot of new reduction on Vista So this suffers from some IE box-sizing quirk(?) but the reporter said on IRC that in strict mode, the red and blue boxes are still on the same line in both cases.
It looks like Firefox is solving the shrink-to-fit equation of CSS2.1 for floats using the available line width instead of the containing block width. http://www.w3.org/TR/CSS21/visudet.html#q8 "Calculation of the shrink-to-fit width is similar to calculating the width of a table cell using the automatic table layout algorithm. Roughly: calculate the preferred width by formatting the content without breaking lines other than where explicit line breaks occur, and also calculate the preferred minimum width, e.g., by trying all possible line breaks. CSS 2.1 does not define the exact algorithm. Thirdly, find the available width: in this case, this is the width of the containing block minus the used values of 'margin-left', 'border-left-width', 'padding-left', 'padding-right', 'border-right-width', 'margin-right', and the widths of any relevant scroll bars. Then the shrink-to-fit width is: min(max(preferred minimum width, available width), preferred width)." Note that the available width is typically the containing block's content width and not the available line width. It sounds like CSS2.1 is not really specific enough for either browser to be incorrect, since the language is pretty vague.
I would not be surprised (given how many float bugs Firefox 3 is fixing) if Firefox 3 matched WebKit. I think this bug is INVALID unless we decide to add a quirk (and I'm pretty reluctant to do so if FFX is going to change to be more like us).
Created attachment 460284 [details] Safari 15.5 matches other browsers I am not able to reproduce this bug based on reduction test case attached in Safari 15.5 on macOS 12.4. All browsers match each other as shown in the screenshot. Can this be marked as "RESOLVED INVALID" or "RESOLVED CONFIGURATION CHANGED"? Thanks! If I am testing incorrectly, please retest accordingly. Thanks!
(In reply to Ahmad Saleem from comment #11) > Created attachment 460284 [details] > Safari 15.5 matches other browsers > > I am not able to reproduce this bug based on reduction test case attached in > Safari 15.5 on macOS 12.4. All browsers match each other as shown in the > screenshot. > > Can this be marked as "RESOLVED INVALID" or "RESOLVED CONFIGURATION > CHANGED"? Thanks! > > If I am testing incorrectly, please retest accordingly. Thanks! Thanks you!