[css-anchor-position-1] position-fallback-bounds vs position-container

[fantasai]

Afaict position-fallback-bounds only affects whether the abspos is considered to overflow for the purposes of triggering fallback positions.

I'm having a hard time understanding what use case it might have that wouldn't be covered by a position-container that actually changes the containing block (and would have many more use cases besides, see e.g. #9662 and the Apple proposal which approximated this by targetting the anchor box).

Assuming that a fixedpos would continue to check its overflow against the viewport in addition to its containing block, do we really need both of these features?

CC @una

[una]

I like the idea of a generic being able to specify containing block, so +1 to using position-container. It seems to solve the same issue.

[css-meeting-bot]

The CSS Working Group just discussed [css-anchor-position-1] `position-fallback-bounds` vs `position-container` , and agreed to the following:

• RESOLVED: Replace position-fallback-bounds with a more generic solution that addresses positioning and not just overflow checks

The full IRC log of that discussion

<emilio> TabAtkins: right now we have `position-fallback-bounds`. Was added via feedback from una, where she noted that an abspos has a regular cb, but for top layer is a bit unfortunate, because it loses the ability to position itself relative to the previous containing-block
<emilio> ... so `position-fallback-bounds` added another set of clipping to the rectangle
<emilio> ... fantasai wanted a more generic some functionality
<emilio> s/some //
<emilio> ... or for top-layer, select any containing block
<iank_> q+
<emilio> ... so fantasai proposed switching to a more generic `position-container` and use that as your containing block modulo restrictions to prevent layout order issues
<emilio> fantasai: so previously `position-fallback-bounds` is added because if your cb is the whole page you might want to check a smaller region of the page
<bramus> q+
<emilio> q+
<emilio> ... so my proposal is to drop position-fallback-bounds and just let you choose the containing-block
<florian> q+
<emilio> ... so when you use position-container, then that becomes the containing block for all purposes
<emilio> chrishtr: so a generic way of overriding the containing block
<astearns> ack iank_
<emilio> iank_: few things, how do you select the containing-block?
<emilio> ... what names it?
<emilio> TabAtkins: wanted to use the anchor-name property as well
<emilio> iank_: so it's the anchor's containing block
<emilio> TabAtkins: no, the element itself
<emilio> iank_: you don't want the containing-block to be an anchor
<emilio> TabAtkins: not the anchor you're using for position, just an element with a different anchor-name
<emilio> iank_: I'd prefer a new property for this
<astearns> [Tab draws]
<emilio> TabAtkins: fine with that [draws in whiteboard]
<emilio> TabAtkins: the element should probably be a relpos so it establishes a containing block etc
<emilio> iank_: you need to select containing blocks that are ancestors of the real containing-block?
<emilio> TabAtkins: yes
<bramus> q-
<emilio> iank_: you need to consider how this interacts with containment
<dholbert> [Tab's drawing showing a containing block rectangle, with an anchor element inside of it. Both of those elements have a defined �anchor-name�. The tooltip uses a �anchor-default� to attach to an anchor, vs. �position-container� to choose its CB, in both cases using the �anchor-name� that's defined for those boxes]
<emilio> ... it'd potentially defeat containment optimizations
<emilio> TabAtkins: maybe? We don't care about containment for anchors
<emilio> iank_: we do
<emilio> TabAtkins: same deal then
<emilio> iank_: how does this work with grid and such magical containing blocks?
<emilio> TabAtkins: want to explicitly define that
<emilio> ... if the named containing block satisfies the rules for an area of it it should still work
<emilio> iank_: I think I'd prefer not to do that
<astearns> q+
<emilio> TabAtkins: we try to capture: if you started as an abspos, and move to the top layer, you shouldn't lose the ability of positioning relative to your previous containing block
<emilio> iank_: tbd on this issues
<astearns> ack emilio
<fantasai> scribe+
<fantasai> emilio: Similar concerns. Part of the reasons people move to top layer is to lose being restricted to that containing block, so if you put the element back into that containing block, how does that interact with clipping etc?
<fantasai> emilio: or is this just about containing block area and rules for positioning
<fantasai> TabAtkins: I think this is just about CB area. We can also discuss being able to clip things in certain ways
<fantasai> TabAtkins: but for now I think this should be focused on the area that you have
<fantasai> emilio: so affects the rules for positioning
<una> q+
<astearns> q--
<fantasai> emilio: you'd override the CB rect to be someone else's rect
<fantasai> fantasai: I think that's what it would do, yes
<fantasai> emilio: ok, that seems less magical than I was afraid
<fantasai> emilio: that solves a lot of the interactions wrt e.g. "what is the offset parent"
<dholbert> q+
<fantasai> chrishtr: so it causes something else to be the container for abspos descendants?
<fantasai> TabAtkins: No, it changes what your containing block rect is
<fantasai> emilio: if you're a top-layer thing, and you select a CB with this property
<fantasai> emilio: your contianing block is still the viewport, just the rect that you position against can be an in-flow child
<fantasai> chrishtr: so constraint rect for the anchor positioning feature would be some other element
<astearns> q-
<fantasai> TabAtkins: Say your nearest CB ('positoin: relative' ancestor) is a scroller
<fantasai> TabAtkins: you want to escape scroller, so you use toplayer
<fantasai> TabAtkins: but you want to be positioned within the bounds of the scroller
<fantasai> TabAtkins: now you can use position-container: --scroller; and you will resolve top/left/bottom/right against the scrolelr's rectangle
<fantasai> TabAtkins: doesn't necessarily adopt that scroller's clip
<fantasai> emilio: is the fallback stuff bound to that rectangle?
<fantasai> emilio: there are use cases for both
<dholbert> scribe+
<dholbert> fantasai (IRC): a lot of the cases where you're not positioning you'd solve with anchor positioning
<dholbert> fantasai (IRC): maybe you're trying to anchor something that's not a scroller, maybe in a sidebar or something
<dholbert> fantasai (IRC): if you overflow the bounds of the sidebar, you fall back to a different position
<dholbert> fantasai (IRC): if there's an element somewhere else in the DOM but you want to position it in the sidebar
<dholbert> emilio (IRC): what if sidebar is larger than viewport
<dholbert> fantasai (IRC): if you're abspos, that's fine, you don't care about it
<dholbert> fantasai (IRC): if you're fixed-pos, you intersect the rects
<dholbert> iank_ (IRC): this only works on fixed things plus top-layer things
<dholbert> TabAtkins (IRC): that's indeed the condition
<dholbert> iank_ (IRC): this won't let you go higher for an abspos
<astearns> ack florian
<dholbert> emilio (IRC): will work for abspos with top layer
<emilio> florian: not entirely sure I understand this but let's assume I do
<emilio> ... kind of annoying to have to name all the things
<emilio> ... the other thing is the target needs to be a valid container
<emilio> ... presumably you walk up the tree after you find that?
<emilio> ... but you could target the bar in your example and it'd walk up
<emilio> TabAtkins: a keyword for "your usual cb" might be convenient
<emilio> ... still subject to all the rules
<emilio> q+
<fantasai> emilio: There's no reason you need to be an abspos containing block
<fantasai> emilio: just need a rect that you can reference
<fantasai> TabAtkins: Yeah, any valid anchor
<astearns> ack una
<fantasai> emilio: as long as you're in that containing block chain
<fantasai> una: I want to ask, does this solve the use cases. I think it does. I like being more generic.
<emilio> una: I wanna answer some of the questions, does it solve some of the fallback bounds?
<emilio> ... I think this solves the use case of having a popover that behaves like a non-popover
<astearns> ack dholbert
<emilio> ... if this is possible I'd like this more generic approach over the fallback bounds
<florian> s/presumably you walk up the tree after you find that/presumably you walk up the tree if the named target isn't a valid container?
<dbaron> [current state of whiteboard is PXL_20240213_200933096.jpg , from a few minutes ago]
<emilio> dholbert: the feature as presented seems like something I might use in the absence of top layer to attach to a different ancestor CB
<astearns> +1 to dholbert (this was what I was on the queue for earlier)
<emilio> ... and if I have an intermediate scroller that'd clip my abspos
<emilio> q+
<emilio> TabAtkins: if you're a normal abspos and there is an intervening scroller that wouldn't be a valid anchor
<emilio> ... it'd need to be below your containing block
<una> having a generic `position-container` (if possible) does include the use cases of `position-fallback-bounds` for anchored popovers and looks like it will solve additional use cases
<emilio> ... because that element is not guaranteed to be laid out
<emilio> dholbert: so the restrictions is the same for valid anchors?
<emilio> TabAtkins: yes
<emilio> dholbert: I think then the name overloading with anchor-name makes sense
<emilio> chrishtr: I think we should not name this container because it's not a containing block, it's a sort of constraining-element
<astearns> ack emilio
<astearns> emilio: was going to bring up the naming stuff
<dholbert> emilio (IRC): I was gonna bring up the naming stuff; since after all, you're not overriding the CB, you're just choosing a different rect to be constrained by
<dholbert> emilio (IRC): and that's fine; +1 to taking naming to the issue
<dholbert> emilio (IRC): maybe we can resolve on this thing, not changing the CB but changing the rect we're relative to
<dholbert> fantasai (IRC): I'm not sure I'm clear on all the stuff discussed, maybe we can take it to the issue
<dholbert> fantasai (IRC): maybe we can resolve on dropping position-fallback-bounds for now, in favor of this thing to be discussed
<dholbert> chrishtr (IRC): in favor of element-based solution?
<astearns> proposed resolution: replace position-fallback-bounds with a more generic solution that addressed positioning and not just overflow checks
<dholbert> fantasai (IRC): a more generic solution , that also affects positioning
<dholbert> TabAtkins (IRC): that lets you swap between your fallbacks based on a different rect. want to let your insets, top/left/bottom/right, be relative to this thing as well
<emilio> https://github.com//issues/9904
<dholbert> emilio (IRC): want to bring up a tangential issue that I filed about top-layer CB, just linked in minutes
<dholbert> emilio (IRC): I think abspsos CB for top layer...there are some things we want to be clear, you may want to choose between inner rect vs. outer rect, i.e. with/without scrollbars
<dholbert> emilio (IRC): +1 to dropping fallback-bounds, +1 to going this direction (of a generic element-defined rect approach)
<dholbert> fantasai (IRC): una and I can work with tab and others to create a proposal
<dholbert> emilio (IRC): there may be use cases for ... I'm in the top layer, but my containing-block rect doesn't need to be constrained by scrollbars. maybe another keyword for this
<astearns> proposed resolution: Replace position-fallback-bounds with a more generic solution that addresses positioning and not just overflow checks
<astearns> RESOLVED: Replace position-fallback-bounds with a more generic solution that addresses positioning and not just overflow checks

[brandonmcconnell]

@fantasai Per my related issue #8762, I think this fixed would be valuable as well unless absolute is expected to work the same in this case as fixed would.

[johannesodland]

Being able to select the containing block would be very useful for sticky positioning.

The element that needs to be sticky might also require a layout that depends on a certain structure. Since the containing block for a sticky element is its nearest block level ancestor, this creates a paradox. The structure that is required for having the correct sticky bounds excludes the structure required for the intended layout.

One example where this is an issue is a menu where only some menu elements should be sticky.

In the screenshot below, the search element should be sticky. It must be a part of the menu container, as it should participate in layout with the other menu elements. Unfortunately, that prevents it from being visually shifted within the page as the menu now becomes its containing block.

A position-container property that allows you to select a different containing block in the containing block chain would help here:

position-container: --main;

Another example is a list of fragment links that are introduced in a section of an article. The article has multiple sections, and the links appear in the introduction section.

At the moment, the links can only be shifted around within the section they descend from, while a position-container property hopefully would allow you to select the article as the containing block:

position-container: --article;

Being able to select the containing block, and being able to configure the insets from that containing block (#10754) would solve many of the issues highlighted in #2496.

I've tried to summarize some of these issues in a post here.

[yisibl]

There are already hundreds of 👍's in these two issues combined, and position-container should work well for these cases.

• [css-position-3] Making a stickypos in a scroller also see the viewport edges #8286
• [css3 positioning] support position:sticky inside an overflow:hidden|auto on general parents #865