Last Comment Bug 99461 - floated boxes drawn over text
: floated boxes drawn over text
Status: RESOLVED FIXED
[WONTFIX?]
:
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: x86 All
: P2 normal (vote)
: Future
Assigned To: Chris Waterson
: Hixie (not reading bugmail)
:
Mentors:
http://www.asciitable.com/
: 111896 117641 (view as bug list)
Depends on: 122200
Blocks: 100552 102445 119433 119654 120087 121090 121632 122197 125943 126065 129470 129677
  Show dependency treegraph
 
Reported: 2001-09-13 07:14 PDT by yoav
Modified: 2014-10-11 16:33 PDT (History)
14 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Reduced testcase. (734 bytes, text/html)
2001-12-24 09:25 PST, Chu Alan
no flags Details
more test-case tinkering (1019 bytes, text/html)
2002-01-02 17:25 PST, Chris Waterson
no flags Details
mono-a-mono (91.47 KB, image/jpeg)
2002-01-02 17:33 PST, Chris Waterson
no flags Details
diff -uw, always check if there's space available regardless of display type (1.09 KB, patch)
2002-01-02 19:23 PST, Chris Waterson
dbaron: review+
Details | Diff | Splinter Review
what buster probably meant (3.02 KB, patch)
2002-01-02 19:56 PST, Chris Waterson
no flags Details | Diff | Splinter Review

Description yoav 2001-09-13 07:14:56 PDT
the dhtml boxes are drwan over the text instead of being drawn to the right (see
in ie).
build 2001091203
Comment 1 Boris Zbarsky [:bz] (still a bit busy) 2001-09-13 08:15:43 PDT
Confirming. There seems to be no positioning going on, no CSS involved, no
floating involved. Quite odd.

Seeing this on Linux as well...

Comment 2 Kevin McCluskey (gone) 2001-10-29 14:50:03 PST
Need reduced test case
Comment 3 R.K.Aa. 2001-11-25 20:15:04 PST
*** Bug 111896 has been marked as a duplicate of this bug. ***
Comment 4 Chu Alan 2001-12-24 09:25:20 PST
Created attachment 62709 [details]
Reduced testcase.

Reduced testcase.

Works good in Netscape, fails in mozilla.
Comment 5 Chu Alan 2001-12-24 09:28:33 PST
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.
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2001-12-24 09:34:39 PST
ccing waterson; looks like a float issue....
Comment 7 Boris Zbarsky [:bz] (still a bit busy) 2001-12-24 09:35:48 PST
Also, setting QA to Ian.  I think that our behavior may actually be correct for 
floaters per the CSS2 spec....
Comment 8 Chris Waterson 2001-12-26 10:41:30 PST
Investigating...
Comment 9 Chris Waterson 2002-01-02 17:25:58 PST
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.
Comment 10 Chris Waterson 2002-01-02 17:33:37 PST
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.
Comment 11 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2002-01-02 17:51:30 PST
IE's behavior here is really ridiculous.  Do we really need to imitate it?
Comment 12 Chris Waterson 2002-01-02 18:02:06 PST
Why is IE's behavior ridiculous? (I have no personal opinion on this, I'm just
curious.)
Comment 13 Hixie (not reading bugmail) 2002-01-02 18:15:06 PST
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.
Comment 14 Chris Waterson 2002-01-02 18:32:29 PST
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.
Comment 15 Chris Waterson 2002-01-02 19:22:12 PST
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 16 Chris Waterson 2002-01-02 19:23:58 PST
Created attachment 63334 [details] [diff] [review]
diff -uw, always check if there's space available regardless of display type
Comment 17 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2002-01-02 19:26:47 PST
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.
Comment 18 Chris Waterson 2002-01-02 19:56:34 PST
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.)
Comment 19 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2002-01-02 20:01:07 PST
Ugh.  Could you at least make it tables-only?
Comment 20 Chris Waterson 2002-01-02 20:09:22 PST
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].
Comment 21 Chris Waterson 2002-01-03 14:58:33 PST
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?
Comment 22 Hixie (not reading bugmail) 2002-01-03 15:30:06 PST
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.
Comment 23 Chris Waterson 2002-01-03 15:51:32 PST
Well, technically, we'd be making a quirk work properly, not adding a new one.
Comment 24 Marc Attinasi 2002-01-07 15:35:07 PST
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.
Comment 25 Chris Waterson 2002-01-08 19:02:10 PST
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.
Comment 26 Chris Waterson 2002-01-08 19:02:51 PST
*** Bug 117641 has been marked as a duplicate of this bug. ***
Comment 27 John Morrison 2002-01-13 21:32:12 PST
> 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).
Comment 28 Alexandru Savulov 2002-02-11 15:13:54 PST
please see analysis on bug 122200

(i have a fix for both bugs, will attach it on bug 122200)
Comment 29 Alexandru Savulov 2002-03-08 13:53:43 PST
fixed by fix for bug 122200

Note You need to log in before you can comment on or make changes to this bug.