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
()
People
(Reporter: ray, Unassigned)
Tracking
({qawanted, testcase})
Firefox Tracking Flags
(Not tracked)
Details
(URL)
Attachments
(2 attachments, 2 obsolete attachments)
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
|
||
Comment 2•14 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•14 years ago
|
||
*** Bug 200944 has been marked as a duplicate of this bug. ***
|
|
||
Updated•14 years ago
|
||
Keywords: testcase
|
||
Comment 4•14 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•14 years ago
|
||
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 6•14 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•14 years ago
|
||
(as demonstrated by the fact that when you fix the MIME type the testcase breaks).
|
|
||
Comment 8•14 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•14 years ago
|
||
Created attachment 171491 [details]
Corrected testcase.
Attachment #168597 -
Attachment is obsolete: true
Attachment #171478 -
Attachment is obsolete: true
|
|
||
Comment 10•14 years ago
|
||
Comment on attachment 171491 [details]
Corrected testcase.
Opera 8.0 beta does indeed render this correctly.|
|
||
Comment 11•14 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•14 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•14 years ago
|
||
Could you attach a testcase for your example? I don't really follow.
|
|
||
Comment 14•14 years ago
|
||
Created attachment 171648 [details]
Sure thing. Testcase for auto-width float example.|
|
||
Comment 15•14 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
Last Resolved: 14 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•