Closed Bug 105520 Opened 23 years ago Closed 17 years ago

table after left float is next to float even when it doesn't fit

Categories

(Core :: Layout: Block and Inline, defect, P1)

Product:
Core
Component:
Layout: Block and Inline
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: kh, Unassigned)

References

(
URL
)

Details

(Keywords: testcase, Whiteboard: [reflow-refactor])

Attachments

(8 files)

Table cell overflow example source
32.36 KB, text/html
Details
simplified test case
693 bytes, text/html
Details
Comparative floater testcase
796 bytes, text/html
Details
Same testcase as "simplified test case", but standards mode
614 bytes, text/html
Details
More comprehensive test
1.73 KB, text/html
Details
Testcase #6
2.00 KB, text/html
Details
Like so?
3.54 KB, patch
Details | Diff | Splinter Review
Is this correct?
281 bytes, text/html
Details
This page apparently loads normally - but ALL of the 'body' text is well to the right of the browser window (ie has been displayed to the right of the table). The main body of the page is a single row two cell table - the second cell contains all of the text apart from page header and footer. The bug is also apparent using xml source - not surprising due to its nature! The pages (the above is not the only one!) were created/tested using the w3c editor/browser Amaya (Windows and linux!) and also render correctly when tested in Oregan Developments Oregano 1.10 browser (used on an Acorn RISC PC). Other offending pages are up to twice the size of the example referred to! This seems to be a bug of long standing - but only just come to light - it certainly occurs in all version of Mozilla back to 0.9 (Netscape 4.1+) that I have been able to test. I understand the fault is also present in the Opera browser - but I have no first hand knowledge of this.
The page has: <table align="left" width="95%"> <!-- Header in here --> </table> <table border="0"> <!-- body in here --> </table> This problem does _not_ occur if the floater is a div. Ccing waterson.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached file simplified test case —
this behavior seems correct to me. the top table is defined with "align='left' width='95%'". this means that the next element will flow directly to it's right, in the 5% of the browser window that remains. the second table tries as hard as it can to wrap itself within that 5%, but can't due to the size of some of it's contained elements. i'm uploading a simplified test case, turning on borders so that you can see the tables more clearly, and removing most of the extra data. opera 5.12, IE 6 and NS 4.78 all render it in more or less the same way (table two beginning at 95% and wrapping as much as it can.) do you expect it to render differently?
flaoater. -->attinasi
Assignee: karnaze → attinasi
Target Milestone: --- → mozilla1.0.1
Keywords: testcase
Moving Mozilla 1.01 bugs to 'future' milestone with priority P1 I will be pulling bugs from 'future' milestones when scheduling later work.
Priority: -- → P1
Target Milestone: mozilla1.0.1 → Future
attinasi will probably not work on those bugs :-(
Assignee: attinasi → table
QA Contact: amar → madhur
Target Milestone: Future → ---
Target Milestone: --- → Future
Actually, if the floater is a div and you don't screw up setting its width you do get identical rendering. mike west is right -- this is invalid.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
But if it can't fit, maybe it should try to be below the float instead of next to it?
True... And that works with text and images. Is the problem that we get an incorrect MES somewhere?
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Summary: Table cell overflow suspected. → table after left float is next to float even when it doesn't fit
We actually probably have an explicit quirk to force it not to wrap, or something ugly like that.
Status: REOPENED → NEW
Er... Except none of the tables here have nowrap attributes set?
The quirk I was thinking of was: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/html/base/src/nsBlockReflowState.cpp&rev=3.475&cvsroot=/cvsroot&mark=884-885,889-938#882 Removing this quirk would make it much easier to fix a bunch of other float bugs since it would allow us to separate the "flow" and "place" parts of "FlowAndPlaceFloater".
But in this case the second table is _not_ floated, so that code shouldn't apply, should it? Agreed that that quirk is ugly. :(
This shows the bug too. So this ain't a quirk.
What's going on starts in nsBlockReflowState::ComputeBlockAvailSpace, but the real problem is that there's no loop in nsBlockFrame::ReflowBlockFrame or nsBlockReflowContext::ReflowBlock like there is in nsBlockReflowState::FlowAndPlaceFloat.
*** Bug 227996 has been marked as a duplicate of this bug. ***
*** Bug 200860 has been marked as a duplicate of this bug. ***
Blocks: 236098
*** Bug 248741 has been marked as a duplicate of this bug. ***
No longer blocks: 236098
*** Bug 236098 has been marked as a duplicate of this bug. ***
*** Bug 244129 has been marked as a duplicate of this bug. ***
*** Bug 278135 has been marked as a duplicate of this bug. ***
*** Bug 284323 has been marked as a duplicate of this bug. ***
Blocks: 287236
*** Bug 285575 has been marked as a duplicate of this bug. ***
I think part of the issue here is that the behavior isn't really specified. I don't think there is any explicit allowance in CSS 2.1 for wrapping tables, images, boxes with overflow set, etc. when they are set to display: block (or display: table; I don't thinnk it matters). The closest thing I can find is http://www.w3.org/TR/CSS21/visuren.html#q15, which does not seem to allow vertically repositioning blocks. The proposed solution seems to be to repeatedly try to place the table further and further down until it fits. This is much closer to wrapping in the inline box model than to floats, which either fit next to the last float or are pushed below it. I guess it would be treated like a cleared element for margin collapsing. However, all of this is just an idea for dealing with the unspecified behavior of floats next to these blocks. In Opera 8 and IE, the block is placed next to the first float it fits next to horizontially, or below all floats if it doesn't fit next to any float. This behavior probably would be an improvement, but it does cause overlaps if a wide float follows a narrow one. I'll attach a testcase that shows what I mean.
I guess the last testcase shows a really bad behavior where part one of the blue rectangles overlaps one of the purple rectangles. This means removing content in case both of the rectangles actually contained something. Since the spec does not say anything clearly at least losing parts of content should be avoided.
Blocks: 290146
The CSS2.1 spec is *completely* clear on this issue. I'm surprised this bug has gone unfixed for almost 4 years: http://www.w3.org/TR/CSS21/visuren.html#floats "The margin box of a table or an element in the normal flow that establishes a new block formatting context (such as an element with 'overflow' other than 'visible') must not overlap any floats in the same block formatting context as the element itself. If necessary, implementations should clear the said element by placing it below any preceding floats, but may place it adjacent to such floats if there is sufficient space."
> I'm surprised this bug has gone unfixed for almost 4 years: That spec hasn't been around for 4 years. If you think this is easy to fix on short notice, feel free to fix it.
> That spec hasn't been around for 4 years. No, it's "only" been around (in final form) for well 1.25 years - and although I believe the original CSS2 spec (7 years old) strongly alludes to the same behavior as explicitly defined in the 2.1 spec, that is clearly irrelevant at this point. What I take issue with is the sentiment that there is ambiguity in the 2.1 spec on this point. The spec states, verbatim, that "the margin box of a table [...] must not overlap any floats in the same block [...]". Any remaining ambiguity must be tied to the case of multiple floats (below each other) of different widths in the same block formatting context and whether a table (or other element) should be shifted below all subsequent floats if it fails to fit next to a given float - or whether the table should be shifted below all floats. The use of the word "clear" may be what is causing the residual confusion: "If necessary, implementations should clear the said element". However, applying the "clear" property would have repercussions outside the formatting context in question, which neither seems logical nor fits well with the remaining language of the specification on this point. The only remaining solution is to move the table (or other) below the float in question when not enough space is available for the two to fit next to each other. In cases where a subsequent float is encountered, and if space is again an issue, the table must be moved further down. The comments of Eli, in particular, are particularly troubling, in that he makes several egregious statements. One example would be that the spec "does not seem to allow vertically repositioning blocks" in this case. That is most evidently incorrect, cf the quote from the spec in my first comment. He furthermore contends that "In Opera 8 and IE, the block is placed next to the first float it fits next to horizontially, or below all floats if it doesn't fit next to any float", while his own following statements and his test case clearly show that the block is indeed not placed below ALL floats, but only shifted down a single float - still leaving an overlap (given circumstances) and thus clearly in violation of the spec. Only 3 rendering options that I can see have any merit whatsoever (i.e. fullfills the letter of the spec): 1. Shifting the table down one float at a time until it fits. 2. Shifting the table below ALL floats in the given block. 3. Clearing the table (by applying the clear property). There is nothing whatsoever that lends any additional weight to the second option and the third option, as noted earlier, strives against the logic and "spirit" of the remaining specification on this point. That leaves the first option as the clearly preferable option.
The original CSS2 spec really doesn't allude to it at all. Please stop posting verbose comments in the bug; we know it's a bug, adding comments will only make the bug more confusing and less likely to be fixed. (FWIW, there may need to be some differences in quirks mode.)
*** Bug 297615 has been marked as a duplicate of this bug. ***
*** Bug 303269 has been marked as a duplicate of this bug. ***
Blocks: 312372
Assignee: layout.tables → nobody
Component: Layout: Tables → Layout: Block and Inline
OS: Linux → All
QA Contact: madhur → layout.block-and-inline
Summary: table after left float is next to float even when it doesn't fit → block-level elements after left float is next to float even when it doesn't fit
Target Milestone: Future → ---
Attached file Testcase #6 —
Mats, I think your retitling is too broad. This behavior applies only to replaced elements, tables, and things that establish new block formatting contexts. We might need separate bugs for some of these, although I may have to fix some for bug 349255.
Summary: block-level elements after left float is next to float even when it doesn't fit → table after left float is next to float even when it doesn't fit
Whiteboard: [reflow-refactor]
Attached patch Like so? — — Splinter Review
This makes us compatible with IE7b2 and Opera 9 for all the cases in Testcase #6, except for a minor difference on the <fieldset>s. For the fieldsets: IE7: text overflows, the block is moved down only when size=0 Op9: text overflows, the block is moved down only when size="some small width (internal padding?)" Gecko with patch: the block is moved down before the text starts to overflow.
Attachment #240283 - Flags: review?(roc)
Comment on attachment 240283 [details] [diff] [review] Like so? I should have said also that the patch fixes all the duplicates and the listed dependent bugs.
You're clearing all floats. Do you really want to do that? Couldn't the block fit next to a narrow float further down?
For tables at least, and probably also for some replaced blocks it's much easier to fix this properly (and without multiple "retry" passes) after the reflow branch lands. I'd prefer if you either (a) wait or (b) work on it on the reflow branch (although non-block-like replaced elements still need some work in nsHTMLReflowState before the fix will work, but that work needs to happen for other reasons too).
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9-
Whiteboard: [reflow-refactor] → [wanted-1.9][reflow-refactor]
Comment on attachment 240283 [details] [diff] [review] Like so? we need a new patch per David's comment
Attachment #240283 - Flags: review?(roc)
Flags: wanted1.9+
Whiteboard: [wanted-1.9][reflow-refactor] → [reflow-refactor]
This is fixed, probably via bug 134706.
Status: NEW → RESOLVED
Closed: 21 years ago → 17 years ago
Resolution: --- → WORKSFORME
Flags: in-testsuite?
Attached file Is this correct? —
In this tesctase, the table is right to the div, even though its 100% wide. I couldn't figure wether this is correct or not, sorry. Could you please tell me?
(In reply to comment #47) > Created an attachment (id=354076) [details] > Is this correct? > In this tesctase, the table is right to the div, even though its 100% wide. > I couldn't figure wether this is correct or not, sorry. Could you please tell > me? This looks fine to me, you said code specified 100%, so what happens, the blue square appears in the browser window, so to have a 100% width, the next piece needs to go underneath. Looks good to me.
(In reply to comment #47) > Created an attachment (id=354076) [details] > Is this correct? > In this tesctase, the table is right to the div, even though its 100% wide. > I couldn't figure wether this is correct or not, sorry. Could you please tell > me? This looks fine to me, you said code specified 100%, so what happens, the blue square appears in the browser window, so to have a 100% width, the next piece needs to go underneath. Looks good to me.
It's the difference to Opera and IE that worries me. Both put the table below the float instead of next to it. I usually "trust" Opera in such cases.
That testcase is showing a variant of bug 25888, except where we're checking something above the top pixel (perhaps due to margin collapsing). It might be worth having a separate bug on file for the block-wrapping-around-floats variants of bug 25888, though.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: