On the http://www.archlinux.org/ website, the logo for the distro is not displayed properly. At first I thought it was a neat style -- but then i saw the image in Firefox an Ubuntu machine.
This is not a regression. I thought it was because the first time I opened the site in Safari 2.0.4 it rendered correctly, but upon reload it didn't. The same goes for TOT: sometimes it will lay out correctly, but when reloaded it won't.
Created attachment 14732 [details] Reduction
Created attachment 14733 [details] Reduction This really isn't about the special layout ignoring stylesheets.
Created attachment 14734 [details] Make diff return Detach if one style is "floating or positioned" and the other isn't Includes change log and layout test. No layout test regressions.
Comment on attachment 14734 [details] Make diff return Detach if one style is "floating or positioned" and the other isn't I don't want to detach in this case. We should be able to handle this without having to do a Detach. (Destroying the entire render tree will make alternate stylesheet switching significantly slower.)
The bug is in the block pref width calculation. Here is a non-dynamic form of the test that shows the layout failure.
Created attachment 14762 [details] Non-dynamic test that shows the bug.
Firefox 3 now uses a pref widths system like we do, and as you can see, they fail the non-dynamic test the same way. The dynamic test still passes in Firefox 3, however, which I can attribute to the fact that they clean up the leftover anonymous block (but we do not). There are two bugs here really: (1) We should have cleaned up the anonymous block (which would fix the dynamic case but not the non-dynamic case). (2) We computed the wrong block pref width. In order to get block pref widths right, we can't naively use a non-floating child's pref widths. We have to actually drill into the child to get better results. I think (1) will be easier, but (2) would of course be more far-reaching and fix some other bugs we have on file in Radar.
Note, though, that CSS3 is planning to formally define the definition of intrinsic width, and it is not going to depend on doing a layout. The spec may actually end up siding with our block pref width result, even though it is "wrong' when compared with WinIE. This is one reason I had held off adding any more complexity to block pref width. http://dbaron.org/css/intrinsic/
In particular, the note in dbaron's draft: "This manner of specifying (and implementing) intrinsic width calculations makes it impossible to specify (or implement) ideal behavior for preferred width of blocks containing floats. The goal of this specification is simply to define an approximation that is good enough, and can be interoperably implemented."
Doing (1) is even pretty tricky, since you're mid-style resolution. It's dangerous to make assumptions about your children inline status when you don't even know what's going to happen to kids that follow you.
This doesn't seem to occur at this site any more, but the reduction still fails with r60936.