the dhtml boxes are drwan over the text instead of being drawn to the right (see in ie). build 2001091203
Confirming. There seems to be no positioning going on, no CSS involved, no floating involved. Quite odd. Seeing this on Linux as well...
Need reduced test case
*** Bug 111896 has been marked as a duplicate of this bug. ***
Created attachment 62709 [details] Reduced testcase. Reduced testcase. Works good in Netscape, fails in mozilla.
i think the problem is here because mozilla does not do "collision" check for two overlapping table that has one left-aligned and right-aligned, so when 2 table is too large, they will become overlapped, or when one of the table use with="100%", mozilla will give the 100% of the whole document area, and it won't exclude the width of another table. The testcase works good in netscape on linux, but fails on mozilla, linux build 200112108.
ccing waterson; looks like a float issue....
Also, setting QA to Ian. I think that our behavior may actually be correct for floaters per the CSS2 spec....
Created attachment 63324 [details] more test-case tinkering Converted one of the tables to a <div>; demonstrate that the table is allowed to flow to its maximum width regardless of whether it's left- or right- floated.
Created attachment 63326 [details] mono-a-mono IE constrains the table's width based on the space taken up by the float; we don't.
IE's behavior here is really ridiculous. Do we really need to imitate it?
Why is IE's behavior ridiculous? (I have no personal opinion on this, I'm just curious.)
IE is wrong. However I don't understand why the floats are overlapping. Shouldn't the second float in both cases go under the first float? I think we already do that correctly for the two-div case, so it's probably a bug in table code.
We do, in fact, get the two-<div> case `right', yet we get it `right' differently than IE does. (IE's behavior with both a right- and left-floated <div> is almost identical to that of a right-floated <table> with a left-floated <div>; that is, the text in the <div> is wrapped so that both fit on the same line. Sigh.) I'll fix this so that we behave identically whether floating a <table> or a <div>; i.e., push the right-float down to the next line.
Aha! More buster fun. It looks like this ``fix'' has to do with bug 37657, which was later un-fixed for <div>s by dbaron in bug 43806. I suspect what buster was trying to do was to implement the IE/Nav4-like behavior where the float is wrapped and placed on the same line if there is still space available on the line. Anyway, this one is easy to ``fix'' by unfixing buster's change all the way. What will we break, I wonder?
Created attachment 63334 [details] [diff] [review] diff -uw, always check if there's space available regardless of display type
Comment on attachment 63334 [details] [diff] [review] diff -uw, always check if there's space available regardless of display type r=dbaron I'd be interested to know how many pages really have problems with this patch -- the bug buster fixed didn't seem to mention more than one page.
Created attachment 63342 [details] [diff] [review] what buster probably meant Of course, attachment 63334 [details] [diff] [review] doesn't fix the god-awful layout of the original test URL (it probably makes it worse, in fact). Here's a more aggressive patch, that attempts to emulate older browsers when in compatibility mode. This patch will ``fix'' the original test case so that it lays out comparably to IE and Nav4. It does this by flowing the floater in the remaining available space, rather than at the full width of the containing block. If we want to consider this patch, it still needs some work: it looks like there is an off-by-one error (e.g., > instead of >=) lurking somewhere that makes it screw up attachment 63326 [details]. Also, were we to use this patch, we may want to revert to the behavior where we'd iterate when the floater couldn't be placed on the current line: that would yield reasonable layout if the float couldn't be placed because of a MES that was too wide, for example. (Or we could just say ``screw it'' and leave the float skinny, maybe that's how Nav4 and IE did it.)
Ugh. Could you at least make it tables-only?
Well, a quirk is a quirk: both Nav4 and IE do the same thing with <div>s. So if the goal is to emulate, we ought to emulate. I'm also okay with tossing this over the transom altogether. (But I'll be a donut that this this will come back as a `topembed' in the future. We can always wait and worry about it then, of course.) FWIW, bug 117641 is almost certainly related to this bug, but is not fixed with attachment 63342 [details] [diff] [review].
On the original test case (attachment 62709 [details]), Win32 IE6 and and Mac IE5.1 both squeeze the right-floated table to fit. On my modified test case (attachment 63324 [details]), Win32 IE6 wraps the floated tables to fit (as do IE5.x and Nav4). Interestingly, Mac IE 5.1 does _not_ wrap the floated table to fit in the second test case. In fact, Mac IE 5.1 treats `align="left"' differently from `style="float: left;"'. Altering the original test case to use the `style' attribute to left-float the table (instead of the `align' attribute) triggers the push. So where do we stand? dbaron has essentially said that he's fine with WONTFIXing this bug, perhaps after applying attachment 63334 [details] [diff] [review] to undo broken table-specific hackery. (This will, unfortunately, make the situation worse for this specific page, and other like it; e.g., bug 117641.) I'm fairly certain Hixie feels the same way. I'm worried about compatibility issues, but don't really want to go tilting at windmills if there are only a handful of pages out there that are affected by this problem. Marc, you were concerned about floater issues last time we talked: how many of the float bugs remaining on your plate might be related to this?
I'm all for checking in attachment 63334 [details] [diff] [review], yes. We could wait to see how many dups we get and reconsider this later. Personally though I'm of the opinion that we should stop adding quirks, and if we ever want to add a quirk we should remove another one first. Note that the CSSWG (including Opera and IE developers) agreed a few months ago that we should not have the behaviour IE has of fitting floats in narrow spaces.
Well, technically, we'd be making a quirk work properly, not adding a new one.
I agree that attachment 63334 [details] [diff] [review] is good to apply. Looking at one of the comments in the bug buster was trying to fix makes me think he was acting on heresay rather than direct evidence: see http://bugzilla.mozilla.org/show_bug.cgi?id=37657#c7 I don't know how knowledgable his web-designer friends were... As for how this relates to the remaining float bugs on my plate, I am no sure. I have not been looking at them in any detail lately, certainly not to the point where I understand their root causese - sorry. sr=attinas on attachment 63334 [details] [diff] [review], BTW.
Okay, I've checked in attachment 63334 [details] [diff] [review]. I'm not going to close this bug, because the page still looks horrible: FUTURE-ing and marking [WONTFIX?] in the status bar. We can see how many of these pile up, and reconsider working on attachment 63342 [review] if it turns out there are lots of them.
*** Bug 117641 has been marked as a duplicate of this bug. ***
> What will we break, I wonder? http://www.tomshardware.com/ http://cowtools.mcom.com/perf/content/base/www.tomshardware.com/index.html (reload and/or narrow browser window, if you don't see several pages of grey background when you first load the live site).
fixed by fix for bug 122200