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)
Tracking
()
RESOLVED
INVALID
People
(Reporter: ray, Unassigned)
References
()
Details
(Keywords: qawanted, testcase)
Attachments
(2 files, 2 obsolete files)
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
Reporter | ||
Comment 1•20 years ago
|
||
Comment 2•20 years ago
|
||
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
Comment 3•20 years ago
|
||
*** Bug 200944 has been marked as a duplicate of this bug. ***
![]() |
||
Comment 4•20 years ago
|
||
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
Comment 5•20 years ago
|
||
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 6•20 years ago
|
||
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
Comment 7•20 years ago
|
||
(as demonstrated by the fact that when you fix the MIME type the testcase breaks).
Comment 8•20 years ago
|
||
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.
Comment 9•20 years ago
|
||
Attachment #168597 -
Attachment is obsolete: true
Attachment #171478 -
Attachment is obsolete: true
Comment 10•20 years ago
|
||
Comment on attachment 171491 [details]
Corrected testcase.
Opera 8.0 beta does indeed render this correctly.
![]() |
||
Comment 11•20 years ago
|
||
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?
![]() |
||
Comment 12•20 years ago
|
||
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.
Comment 13•20 years ago
|
||
Could you attach a testcase for your example? I don't really follow.
![]() |
||
Comment 14•20 years ago
|
||
![]() |
||
Comment 15•20 years ago
|
||
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.
Description
•