Closed Bug 16056 Opened 25 years ago Closed 25 years ago

fixed-positioning clipping needs work

Categories

(Core :: Layout, defect, P3)

Other
Windows 95
defect

Tracking

()

VERIFIED DUPLICATE of bug 4209

People

(Reporter: aaron_bentley, Assigned: troy)

References

()

Details

When fixed positioning is in use and a fixed-positioned element is obstructed by another positioned element, strange things appear in the obstructed area. For me: "Reload, Customize. . ." To see for yourself, go to the example page and resize the browser until only the "s i d" from "s i d e b a r" is visible. Other fixed-positioning issues: by default, fixed-positioned elements have a width and height such that they take up the entire screen. Fixed positioned elements appear to have a higher z-index than absolutely positioned elements created after them.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
DUP of bug #4209. There are several known compositor bugs related to absolute positioning As far as the other two issues go: - by default, fixed-positioned elements have a width and height such that they take up the entire screen. That's the way CSS2 works. See the CSS2 spec for details - Fixed positioned elements appear to have a higher z-index than absolutely positioned elements created after them. Fixed positioned elements are children of the viewport, and absolutely positioned elements children of the initial containing block (document element's box), therefore they will be higher in the stacking order *** This bug has been marked as a duplicate of 4209 ***
Status: RESOLVED → REOPENED
Okay, I can understand the z-positioning issue. If being a child of the viewport permits percentile widths and heights based on the viewport, that's a Good Thing. Regarding width and height however. . . CSS2 9.6.1 "Fixed positioning is a subcategory of absolute positioning. The only difference is that for a fixed positioned box, the containing block is established by the viewport." In Mozilla M10, an absolutely positioned positioned element with content "foo" is just wide enough and just tall enough to contain "foo" (since "foo" doesn't wrap given reasonable screen size and font size). Since the only difference is the parent of the element, a fixed-positioned element with content "foo" should be just wide enough and just tall enough to contain "foo" (since "foo" doesn't wrap given reasonable screen size and font size). I can't see how the element's parent could have any impact on this, and that is the only difference.
Resolution: DUPLICATE → ---
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → DUPLICATE
This is why you shouldn't put three separate problems in one bug report. I marked it a DUP because of the main problem you describe. Changing it back to DUP again As far as the problem of shrink wrapping width/height goes, what's happening with fixed positioned elements is correct. You may not like it, I don't like it either, but that's how it's defined in the CSS2 spec. See sections 10.3.7 and 10.6.4 for details. To summarize, though, for a specified value of 'auto', the absolutely positioned element's box plus offset sums to be equal to the containing block's width/height. The reason you're seeing different behavior for absolutely positioned elements vs. fixed positioned elements is because the viewport's height is constrained where as the initial containing block's height defaults to 'auto' That's another area where the CSS2 spec is not well defined.
*** This bug has been marked as a duplicate of 4209 ***
Status: RESOLVED → VERIFIED
Marking as verified duplicate of 4209.
You need to log in before you can comment on or make changes to this bug.