[css-position-3] List all specified properties that establish a containing block for fixed-position elements

[gitspeaks]

The note in Section 2.1. Containing Blocks of Positioned Boxes states:

Properties that can cause a box to establish a fixed positioning containing block include transform, will-change, contain…

The ellipsis (…) at the end suggests this is not an exhaustive list.

Please list all relevant specified properties that cause an element to establish a containing block for fixed-position descendants.

[Loirooriol]

The list is not exhaustive indeed.

Listing all possibilities seems problematic from the maintenance point of view, the list would easily become obsolete.

Also, css-position-3 is just a WD, but let's say it becomes a REC at some point. A new WD spec may add a new property that establishes a containing block for fixed-position elements, but adding it into the list would be problematic.

If you are just trying to satisfy your curiosity, you can check the source code of some browser:

• https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/layout/layout_object.cc;l=1831-1882;drc=f667feb8a5c6f227b49328ce78a062acc4f81187
• https://searchfox.org/wubkat/rev/07dade918043f99fb9ff8d13cbba3414b85a054d/Source/WebCore/rendering/RenderElementInlines.h#101-113
• https://searchfox.org/mozilla-central/rev/2c71f1e9b5947612abdc16b64008162c58c1b9d3/layout/style/ComputedStyleInlines.h#97-117
• https://github.com/servo/servo/blob/da4ea0f0965414733f0352e76ff416b1ded75a08/components/layout_2020/style_ext.rs#L793-L826

[gitspeaks]

Looking at the code references you provided, it seems that all browsers agree - or at least should agree - on a relatively fixed set of properties: transform, will-change, contain, filter, and backdrop-filter.

In particular, looking at Chrome’s codebase, I don’t see any substantial changes to this logic over the past six years (see this 2019 reference). So, I don't find the "maintenance concern" particularly compelling. There’s no evidence that the list is changing frequently or at risk of becoming obsolete quickly.

I also didn’t quite follow your point regarding REC vs WD. Specifically, I don’t see why it would be "problematic" to update the list in the future if a new property is added. Specs are updated all the time - updating a list like this to reflect changes doesn't seem any more burdensome than updating other parts of a spec.

In any case, I suggest explicitly adding filter and backdrop-filter to the list. I also recommend removing the ellipsis at the end - it doesn’t really serve a purpose here. Ellipses are typically used to suggest a continuation based on a clear pattern, but there’s no such pattern here, so it just reads oddly.

If maintaining an exhaustive list is indeed a concern, I would suggest rephrasing the note as follows:

Properties that can cause a box to establish a fixed positioning containing block include, but are not limited to, transform, will-change, filter, and backdrop-filter. This is not an exhaustive list; CSS properties that cause a box to establish such a containing block should document this behavior explicitly in their respective specifications.

[Loirooriol]

From a quick look at the code, your list is not exhaustive either.

[gitspeaks]

From a quick look at the code, your list is not exhaustive either.

What property is missing?

[Loirooriol]

For starters, several transform-related properties: rotate, scale, translate, transform-style, perspective, backface-visibility. And come on, I already linked to code, just read it properly.

[gitspeaks]

Honestly, I shouldn't have gone digging through implementation code you referenced to begin with — that’s not where specs should be clarified. I only added filter and backdrop-filter because Chrome’s code explicitly links them to spec-defined behavior.

As for rotate, scale, and translate: these are values of the transform property, not standalone properties. The spec is already clear:

"Any value other than none for the transform property also causes the element to establish a containing block for all descendants. Its padding box will be used to layout for all of its absolute-position descendants, fixed-position descendants, and descendant fixed background attachments."

If an implementation only defines containing block behavior for a subset of values, that’s a conformance issue — not something this issue is about.

Regarding transform-style, perspective, backface-visibility: fair enough. Their effect just reinforces my original ask because the lack of a centralized list leads to inconsistent documentation. For example: MDN, list some of the properties but not others, and even warns about inconsistencies:

"If the position property is absolute or fixed, the containing block may also be formed by the edge of the padding box of the nearest ancestor element that has any of the following:

• A filter, backdrop-filter, transform, or perspective value other than none.
• A contain value of layout, paint, strict or content (e.g., contain: paint;).
• A container-type value other than normal.
• A will-change value containing a property for which a non-initial value would form a containing block (e.g., filter or transform).
• A content-visibility value of auto."

and

"Note: There are browser inconsistencies with perspective and filter contributing to containing block formation."

[Loirooriol]

I shouldn't have gone digging through implementation code you referenced to begin with — that’s not where specs should be clarified

The spec has no need to list all properties that may establish a fixed CB in a centralized place. If you want this information, it's on you.

As for rotate, scale, and translate: these are values

They are properties: https://drafts.csswg.org/css-transforms-2/#individual-transforms

[gitspeaks]

The spec has no need to list all properties that may establish a fixed CB in a centralized place. If you want this information, it's on you.

I disagree - it should. Centralizing this kind of information improves clarity and consistency.

They are properties: https://drafts.csswg.org/css-transforms-2/#individual-transforms

Sure, but that’s beside the point. The corresponding transform functions already fall under the behavior defined for the transform property. Whether they’re used via values or as individual properties, the effect is the same - the containing block behavior is already accounted for. Listing them again as separate “properties” doesn’t add anything meaningful. The original text already mentions transform, which implicitly includes these.