Closed Bug 274387 Opened 20 years ago Closed 20 years ago

div top margin incorrectly applied to earlier sibling absolutely positioned div

Categories

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

Product:
Core
Component:
Layout: Block and Inline
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: ray, Unassigned)

References

(
URL
)

Details

(Keywords: qawanted, testcase)

Attachments

(2 files, 2 obsolete files)

Corrected testcase.
422 bytes, application/xhtml+xml
Details
Sure thing. Testcase for auto-width float example.
582 bytes, text/html
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041212 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041212 In the above URL the "Jigsaw" image appears too low, on top of the heading text. The simple example (j.html) below shows the two div texts t1 and t2 on smae horizontal line. t1 should be at top left but has been moved down to be in line with t2. Reproducible: Always
Attached file simple example (obsolete) —
Confirming. This is not a recent regression, I can see the bug even in Mozilla1.4 (before that, more things are going wrong).
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 200944 has been marked as a duplicate of this bug. ***
Keywords: testcase
Er... isn't this the right behavior? The margin collapses with the body margin, which pushes down the placeholder for the auto-offset absolutely positioned div. Just putting a border on the body will prevent margin-collapse here and put the div in the "right" place. Ian, what's the right collapsing behavior here?
Keywords: qawanted
Attached file Same testcase, but in standards mode (obsolete) —
Well, according to: http://www.w3.org/TR/CSS21/box.html#collapsing-margins, the 4th list-item: "Margins of absolutely positioned boxes do not collapse (not even with their in-flow children)." I don't expect a margin collapse here. Opera7.54 doesn't do margin collapsing here, so I think it is a bug of Mozilla.
Comment on attachment 171478 [details] Same testcase, but in standards mode Fixing MIME type. Please don't use XHTML unless you use the XHTML MIME type, it's just confusing otherwise.
Attachment #171478 - Attachment mime type: text/html → application/xhtml+xml
(as demonstrated by the fact that when you fix the MIME type the testcase breaks).
Anyway, the correct rendering (when you fix the testcase to use correct selectors) is somewhat undefined, since it relies on the definition of "static position", which is left up to UAs (UAs are allowed to guess). The ideal position would be that the first <div> (the positioned one) is about 180px from the second one, because if it wasn't positioned, that's where it would be. Mozilla's rendering is incorrect per this ideal, because it is positioning the <div> as if it was a float, not as if it was a static in-flow box.
Attached file Corrected testcase. —
Attachment #168597 - Attachment is obsolete: true
Attachment #171478 - Attachment is obsolete: true
Comment on attachment 171491 [details] Corrected testcase. Opera 8.0 beta does indeed render this correctly.
Who said anything about the margins of the abs-pos div collapsing? The margins of the div with a margin set are what collapse. There's a circular dependency here -- if the abs pos div were static pos, the margins would not collapse, and the <body> top content edge would be in a different place from where it actually is. But as things stand, we're placing the "this is t1" at the position of the first line box in the <body> Ian, what makes you say that Opera's behavior here is correct? Should the "this is t2" div's margin not collapse with the body margin?
Ok, I see what Hixie's saying about "as if it were a float". The way Mozilla implements the verbiage about "as if it had static position" is by laying out all in-flows (which it has to do anyway) and then looking where in the resulting document the box would have been if it had static position. In this case, that leads to the observed layout, of course. The alternative would be to actually do an extra reflow of everything for every auto-offset abs pos element that you have around. This would be needed, to get that "ideal" rendering, in the case of an auto-width parent float whose width would be affected by the abs pos element if it were static pos such that the float would no longer fit where it's placed currently (Ian, does Opera get this "right"?). This approach is really quite inefficient, and I question the "ideal" being put forth here. Given that the language in the specification is there for compat with IE, I think simplicity of specification is being prized over simplicity of implementation here... It may be worth revisiting what the specification says with an eye towards simpler and easier to understand behavior.
Could you attach a testcase for your example? I don't really follow.
So to answer my own question, Opera 8.0 Beta 1 on Linux gets my testcase "wrong".
I'm marking this INVALID since the spec gives us latitude here.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: