Closed Bug 202449 Opened 22 years ago Closed 22 years ago

float right inside column placed incorrectly vertically

Categories

(Core :: Layout: Floats, defect)

Product:
Core
Component:
Layout: Floats
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: kurtis, Unassigned)

References

(
URL
)

Details

(Whiteboard: [technote-needed] (o109923))

Attachments

(2 files)

Test case of floating divs
1.76 KB, text/html
Details
test case involving wrapping text
18.21 KB, text/html
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030411 Phoenix/0.5+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030411 Phoenix/0.5+ In Mozilla 1.3 the example webpage layout is correct (i.e. the byline in the weblog summaries in next to the title) where as in Mozilla 1.4a the byline layout seems dependent on the length of the DIV in the left column of the page, but only if it is followed by another left column DIV. Since the byline is completely contained within at least two container tags, its layout shouldn't be dependent on anything outside those tags. Reproducible: Always Steps to Reproduce: 1. Go to http://www.profoundmystery.org/bug/test2.html -- the main page also shows the bug, but the test2.html page has been stripped down to the minimum I think shows the bug. Additionally, there are comments in test2.html that show how to make the layout correct at the expense of the extra left DIV. Actual Results: The byline layout places it on top of other text, and places all three bylines together. Expected Results: The bylines should be placed next to the titles of the web summaries. This is the behavior in Mozilla 1.3 and earlier. Contact me if you need any additional information. I am submitting this report within a Phoenix nightly, but I also see this problem with Mozilla 1.4a.
Per CSS, a float must not start before the top of a float that came before it in document order. So the floats on the left push down the ones on the right, and this seems correct.... That said, I recall David filing a bug on part of this behavior recently. ccing him so he'll hopefully look when he gets back.
After reading the CSS description of floats, it does say floats earlier in the document, and not floats earlier in the document and within the same container, so it seems this behavior is appropriate, and not a bug. However, this totally sucks, since it means floats are totally independent of all container tags, and the only way to do this kind of formatting is to use tables, which CSS is moving us away from. You can close this as defined behavior. It's just another limitation of the CSS formatting rules.
Yeah, I think that was it. I'm not quite sure of what the correct behavior in this bug is, basically..
Yeah, our behavior here is correct. However, it's worth noting that you can get the behavior you want if the DIV containing the inner floats (i.e., the right column) were itself a float.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
*** Bug 205673 has been marked as a duplicate of this bug. ***
*** Bug 206391 has been marked as a duplicate of this bug. ***
*** Bug 208775 has been marked as a duplicate of this bug. ***
*** Bug 210811 has been marked as a duplicate of this bug. ***
Adding a suggestion for a technote to be written up on this issue to the whiteboard.
Status: RESOLVED → VERIFIED
Whiteboard: [technote-needed]
You know, it is important to note that Mozilla is the only browser that believes this is correct behavior. Yes, a strict reading of the standard seems to go this way, but Safari, IE, and Opera (and I think Konqueror and Gnome's browser too) all render it the other. Consider: http://www.bigbaer.com/css_tutorials/css.image.text.wrap.tutorial.htm http://www.bigbaer.com/images/css-text-wrap-moz.jpg or: http://archivist.incutio.com/viewlist/css-discuss/32470 or: http://www.forum4designers.com/archive29-2004-5-78289.html or, in particular: http://lists.w3.org/Archives/Public/www-style/1998Dec/0065.html which discusses this as a bug in the specification. Now, I understand wanting to be compliant, but it seems to me that actually making this do the standards correct behavior is: 1) harder and messier to program 2) unintuitive 3) has no useful purpose (nobody has shown me a page which relies on Mozilla's behavior or a layout which is made simplier by Mozilla's behavior) 4) may be going away in a future version of the standard anyway, meaning if (3) ever did exist, we'll end up breaking it later anyway So, why can't we change this behavior back to the way it was before Mozilla 1.3, and back to the way every other browser has decided to interpret that part of the spec?
Kurtis, can you point to a testcase that we render differently from Opera 7.5+, please?
Done. Here is a test case since the one hosted on my site went away.
Under Opera 7.54 under Windows and IE under Windows (just tested a few minutes ago to double check) the div with the green border shows up inside its container div (which might be, for instance, a story entry, with the green border div being a topic image) while under Mozilla it gets pushed below the divs on the left (which might, for instance, be blocks of varying widths for announcements or something.)
If the boxes are too wide, you'll need to change the CSS width entries to 150px (I forgot the units). On further testing (it wasn't this way too long ago, though I don't remember exactly how long ago) it appears the KHTML browsers (Konqueror and Safari) now do Mozilla's behavior of putting the div at the same level as the bottom one, though the behavior doesn't seem useful at all. So, of the four rendering engines I can test, two do it one way and two do it the other: Gecko and KHTML: align with top of the fourth left floating div IE and Opera: put inside container div I know KHTML didn't use to do this... they probably started after Mozilla pointed out the "error" in the spec and started doing it this other way that isn't actually useful but is the standard. I really do recommend reading http://lists.w3.org/Archives/Public/www-style/1998Dec/0065.html if one has time for discussion of this issue before the implementations started "breaking" by following it to the letter.
(In reply to comment #15) > I really do recommend reading > http://lists.w3.org/Archives/Public/www-style/1998Dec/0065.html It's been read. Note that the author of that mail is the one who marked this bug invalid in comment 5. I fully expect the next Opera revision to be interoperable with Gecko and khtml on this.
I had noticed, but since he hadn't said anything since then (and, I assume, since he wrote that posting he agreed that the spec was somewhat screwy) I thought maybe someone else could enlighten us on the issue. It sounds like he was assuming that the spec was wrong, posted for clarification on the w3 list, didn't get a response (or got the response I'm looking for) and then pointed out over here that the Mozilla behavior was out of spec, filed the bug 196919 and then fixed it. Other browsers then followed suit. I'll go away and seek answers in another forum, but can anybody here give me a reason why the spec reads this way? What possible good reason can there be for this behavior, especially when Opera and IE don't read it this way?
Anyway, it seems most of this discussion is moot, as CSS3 says (I think): Principle of preservation of ordering: The top margin edge of a floating box may not be higher than the top margin edge of any float or block-level box in the current flow that is generated by an earlier element in the document. That "in the current flow" part seems to imply that Opera's behavior is correct for CSS3, since in the attached example the left float is in another flow. At least, that's how I read it. I am just totally wrong?
Why is it in another flow? Please look up the definition of block formatting contexts (at http://www.w3.org/TR/CSS21/visuren.html#q15). Each block formatting context establishes a separate flow inside itself. In your case, the two "container" divs don't establish block formatting contexts, however.
Okay. It doesn't create a new block rendering context, it (I assume) uses the existing one. Mea culpa. Anyway, it doesn't matter. I'm sure you know the spec better than I do. Clearly this is an area where the spec is either unclear or unuseful, or both. That's fine. If this is the reading, then it is very obvious that the spec never intends multiple column layout. All the ways (short of absolute positioning) of doing multiple column or sidebar layout are hacks, since they can't be nested. I'll wait another year, see if Opera is still doing it the other way, then mention it again.
The way to do multi-column layouts is using CSS tables (display: table-cell, etc). A clearer testcase for Opera's bug here is: http://www.hixie.ch/tests/adhoc/css/box/float/041.html I can't promise we'll have this fixed in the next release, but we do acknowledge this as an Opera bug.
Whiteboard: [technote-needed] → [technote-needed] (o109923)
The problem is table-cell and others basically ask us to go back to the old days of tabled layouts, just without using the <table> tags. For instance, this attachment shows a layout whereby text flows around divs on both the left and the right. Opera right now will put the "topic graphic" to the right of the posting (where it should go according to my design) but Mozilla will push all of them down below the floats on the left. If your reading of the spec is correct, then this kind of layout is impossible. Perhaps what is actually needed is a way to specify a kind of float that doesn't follow rule 5?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: