Closed
Bug 2261
Opened 26 years ago
Closed 26 years ago
absolute positioning not being done relative to containing block
Categories
(Core :: Layout, defect, P2)
Tracking
()
VERIFIED
FIXED
M4
People
(Reporter: dbaron, Assigned: troy)
References
()
Details
Absolute positioning is not being done relative to the containing block (as it
should be). It is instead being done relative to BODY. The rules for
calculating the containing block are quite complicated, but, when such an
element exists, it is the padding edge of the closest ancestor element that has
position: relative or absolute. The details are given in:
http://www.w3.org/TR/REC-CSS2/visudet.html#containing-block-details
This bug, in addition to being easily visible in the URL above, also causes a
slight misalignment in my homepage (recently made harder, since you are doing
well on it!): http://www.fas.harvard.edu/~dbaron/
I am assigning this to troy since he has been working on this (I think), but
cc:ing Kipp anyway.
Actually ot's being done rekative to the HTML element which is the 'initial
containing block'. That's a relatively recent change, and previously it was
relative to the BODY
The main problem we have today is that we're not treating relatively positioned
elements as a container for child absolutely positioned elements (we are
treating absolutely positioned elements as a container for child absolutely
positioned elements, though)
|
Reporter | |
Comment 2•26 years ago
|
||
A really weird problem just appeared on the above URL. (sec090302a) The
element with class="seven" makes the page miles long (i.e., holding down PageDn
doesn't cause a noticeable change in the scrollbar until after about ten
seconds), and appears intact at the very bottom. I'm impressed that you
"handled" a page "that long," but...
|
|
Reporter | |
Comment 3•26 years ago
|
||
By "just appeared" I mean between the builds of 99-01-08 and 99-01-13.
I fixed the weird problem with class="seven" causing a giganticly sized box
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
I'm marking this fixed, because the main point of the bug is addressed and we
support absolute positioned elements inside of relatively positioned contained
blocks.
You'll notice the page doesn't display perfectly for two reasons:
1. there's a problem in the view code where we're clipping child views where we
shouldn't
2. in the 'right' test there looks like a problem in the test
In the 'right' test
(http://www.fas.harvard.edu/~dbaron/csstest/sec090302b.html), we don't display
the P at the right edge of the containing block because the "div.contain p {
background-color: yellow; margin: 20px 0; padding: 0; border: none; }" rule
overrides the 'margin-left:auto' rule
|
|
Reporter | |
Updated•26 years ago
|
Status: RESOLVED → REOPENED
|
|
Reporter | |
Comment 6•26 years ago
|
||
This has regressed back to its old behavior as of the 98-02-01 build.
Reopening bug.
Can you be more specific in what you think has regressed? The original bug was
because we didn't properly handle absolute positioned elements inside of a
relative positioned element.
That hasn't regressed. Here's an example that looks fine for me, using the
latest build anyway
<body>
<p>A paragraph
<p style="position:relative; left:50px; top:150px">A second paragraph that's
relatively positioned and
that has a fixed image_ <img src="house.gif" style="position:absolute;
top:100px" width=50 height=50> image that's
contained within it
</body>
|
|
Reporter | |
Comment 9•26 years ago
|
||
My homepage has regressed. The stuff at the top of the page is now moved to
the left into BODY's padding, even though it is in a relatively positioned
container.
|
Assignee | |
Comment 10•26 years ago
|
||
The problem is that the parser is moving the nested SPAN element outside of the
H1 and that's why the containing block is incorrect. I created a new bug# 2871
assigned to rickg
I'm marking this as FIXED again, because the original problem is fixed and this
is a different problem
|
||
Comment 11•26 years ago
|
||
verified on
win95 - 99030910
redhat 5.2 - 99030908
You need to log in
before you can comment on or make changes to this bug.
Description
•