This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
roc reported that our wording about transforms establishing containing blocks is incorrect: http://lists.w3.org/Archives/Public/www-style/2012Aug/0248.html Øyvind agreed, and further pointed out that a "containing block" is a box, not an element: http://lists.w3.org/Archives/Public/www-style/2012Aug/0264.html He suggested that we define precisely how we're modifying the CSS 2.1 requirements, rather than using undefined terms like "establishes a containing block for positioned descendants". I suggest wording like the following: """ Any value other than ‘none’ for the transform results in the creation of a stacking context. The containing block of an element with 'position: fixed' is the padding edge of its nearest ancestor with a 'transform' other than 'none'. If there is no such ancestor, its containing block is as specified in CSS 2.1. The containing block of an element with 'position: absolute' is determined as specified in CSS 2.1, except that an ancestor element with 'transform' other than 'none' is treated the same as one with a 'position' of 'absolute', 'fixed', or 'relative'. """ With suitable links to the relevant sections of CSS 2.1. I think the "is treated the same as" wording is the best available here, because it's quite clear but doesn't require duplicating the different handling for inline vs. block ancestors. Also, Øyvind points out that we currently have two places where this requirement is stated, slightly contradictory: """ In the HTML namespace, any value other than ‘none’ for the transform results in the creation of both a stacking context and a containing block. The object acts as a containing block for fixed positioned descendants. """ """ Any value other than ‘none’ for the transform results in the creation of both a stacking context and a containing block. The object acts as a containing block for fixed positioned descendants. """ Is is only in the HTML namespace, or not? I suggest removing the second entirely, and replacing the first with text like what I give above. Any objections to my proposed change?
Seems fine.
I don't think I'll have time to do this. Someone else should feel free -- it should be simple.
*** This bug has been marked as a duplicate of bug 16328 ***