Closed Bug 99461 Opened 22 years ago Closed 22 years ago

floated boxes drawn over text


(Core :: Layout, defect, P2)






(Reporter: stakadush, Assigned: waterson)




(Whiteboard: [WONTFIX?])


(3 files, 2 obsolete files)

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

Ever confirmed: true
OS: Windows 2000 → All
Need reduced test case
Keywords: qawanted
Target Milestone: --- → mozilla1.0
*** Bug 111896 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.0 → mozilla1.2
Attached file 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
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....
QA Contact: petersen → ian
Assignee: attinasi → waterson
Priority: -- → P2
Summary: dhtml boxes drawn over text → floated boxes drawn over text
Target Milestone: mozilla1.2 → mozilla0.9.8
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-
Attached image mono-a-mono
IE constrains the table's width based on the space taken up by the float; we
Blocks: 117641
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
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?
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.
Attachment #63334 - Flags: review+
Attached patch what buster probably meant (obsolete) — Splinter Review
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

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

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.
Blocks: 118426
No longer blocks: 118426
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  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.
Whiteboard: [WONTFIX?]
Target Milestone: mozilla0.9.8 → Future
No longer blocks: 117641
*** Bug 117641 has been marked as a duplicate of this bug. ***
Blocks: 119654
> What will we break, I wonder?

(reload and/or narrow browser window, if you don't see several pages of grey 
background when you first load the live site).
Blocks: 119433
Blocks: 120087
Blocks: 121090
Blocks: 121632
Blocks: 122200
Blocks: 122197
please see analysis on bug 122200

(i have a fix for both bugs, will attach it on bug 122200)
Blocks: 102445
No longer blocks: 122200
Depends on: 122200
Blocks: 125943
Blocks: 126065
Blocks: 100552
Attachment #63334 - Attachment is obsolete: true
Attachment #63342 - Attachment is obsolete: true
Blocks: 129470
Blocks: 129677
No longer blocks: 119654
Blocks: 119654
fixed by fix for bug 122200
Closed: 22 years ago
Resolution: --- → FIXED
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.