User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070723 Iceweasel/2.0.0.6 (Debian-2.0.0.6-0etch1) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8pre) Gecko/2007082201 SeaMonkey/2.0a1pre the layout of the page can not be rendered properly. Reproducible: Always Steps to Reproduce: 1.open http://chat.icq.com Actual Results: the layout of the page is broken Expected Results: page is rendered properly

It's a regression from bug 300030. I think we're calculating the "available width" in 10.3.5 wrong - we should subtract the width of the first float ("d1-2"). http://www.w3.org/TR/CSS21/visudet.html#float-width

The available width very clearly doesn't say to subtract widths of other floats. If that happens at all, it should be quirks mode only. It causes very bad behavior with multiple floats. That said, that's not the only possible reason other browsers might behave differently on that testcase.

(In reply to comment #3) > The available width very clearly doesn't say to subtract widths of other > floats. Right, I missed that somehow... So, the current layout looks to be in accordance with the spec then. FWIW, Safari/Webkit have the same layout as Firefox trunk. IE7 and Opera 9.20 places the floats to the right as Firefox 1.5/2.0.

Slightly more reduced testcase.

I made a reftest from Testcase #2

It seems to me this is the bug why http://www.flexmarkt.nl/ is looking wrong now in current trunk build.

(In reply to comment #7) > It seems to me this is the bug why http://www.flexmarkt.nl/ is looking wrong > now in current trunk build. fwiw, that site displays the same in Safari 2.04, Safari 3beta and latest WebKit builds as it does on current Gecko trunk builds.

(In reply to comment #7) > Created an attachment (id=285356) [details] > testcase, deduced from flexmarkt.nl > > It seems to me this is the bug why http://www.flexmarkt.nl/ is looking wrong > now in current trunk build. > So, just trying to understand this bug. The CSS 2.0 specifications recommend to give a width for every floated element. Actually in this testcase, if you give a width to the floated element, it will render properly. According to CSS 2.1 specifications, this isn't necessary anymore and browsers should render it properly, meaning the floated element should take the width from content. Since FF3.0 get parent's width I consider this is a bug...

CSS2.1 specifically says what information is used in the shrink-to-fit algorithm (although it doesn't define the algorithm precisely); the available width inside the containing block is used; the positions of other floats or space next to them are not. Doing what you propose has very bad consequences when pages are resized, since floats can become very tall and narrow before "wrapping", breaking the layout much more severely than it would be if they "wrapped" earlier.

I'm also seeing this problem on http://www.zdnet.be/news.cfm?id=88954&mxp=100 .

All the testcases look exactly the same on Nightly, Chrome 31 and IE 11.

I think INVALID is more accurate here, since we're choosing not to fix the bug as reported, and choosing not to fix matches the relevant specs (and other browsers).