All users were logged out of Bugzilla on October 13th, 2018

div top margin incorrectly applied to earlier sibling absolutely positioned div

RESOLVED INVALID

Status

()

RESOLVED INVALID
14 years ago
14 years ago

People

(Reporter: ray, Unassigned)

Tracking

({qawanted, testcase})

Trunk
x86
Windows XP
qawanted, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

14 years ago
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

14 years ago
Created attachment 168597 [details]
simple example
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
Created attachment 171478 [details]
Same testcase, but in standards mode

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.
Created attachment 171491 [details]
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.
Created attachment 171648 [details]
Sure thing.  Testcase for auto-width float example.
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
Last Resolved: 14 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.