16056 - fixed-positioning clipping needs work

Status: VERIFIED DUPLICATE of bug 4209

(Core :: Layout, defect, P3)

Description

[aaron_bentley]

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.

Comment 1

[troy]

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 ***

Comment 2

[aaron_bentley]

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.

Comment 3

[troy]

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.

Comment 4

[troy]

*** This bug has been marked as a duplicate of 4209 ***

Comment 5

[Chris Petersen]

Marking as verified duplicate of 4209.