[css-position-3] Making a stickypos in a scroller also see the viewport edges

[tabatkins]

Across multiple issues (and especially in #865), a persistent complaint from authors seems to be that if a stickypos element has a scrolling ancestor, it will no longer stick to the viewport edges.

For example, a table that wants sticky headers, but is wide and thus wants to be horizontally scrollable, can't be done - the headers only care about sticking in the table's own scroller, which doesn't even scroll in the vertical axis.

(See #865 (comment) from @valtlai for an example and demo.)

Even if we can't care about arbitrary ancestor scroll containers, the special case of caring about the outermost viewport seems high-value to address.

Can we consider doing this either always, or through a new keyword?

[vexx32]

I feel like having a sticky-x and sticky-y distinction might potentially be helpful...

Feels like half the problem is that the sticky thing is too confused about what directions are meant to be scrolled by the element vs the viewport in many cases.

[tabatkins]

Which axis an element is sticky in is already clear, from which axis it has non-auto insets in. (That is, a sticky element with only "top: 0" is clearly only vertically sticky.)

[bramus]

In #7475 (comment) I pondered about making position a longhand, allowing authors to also specify a reference thing to calculate the positioning against.

Maybe for position: sticky this could be:

• position: sticky / ancestor (default)
• position: sticky / viewport
• position: sticky / sibling <integer>

For that third item in the list above a extra<integer> is needed to specify the level of stickiness. That way, one can stick elements against other stuck siblings, to form some sort of stack. See #2496 (comment) for earlier thoughts and more details on this. One major downside though is that this would be z-index struggles all over again.

Also, when you say viewport I think you mean the Layout Viewport but maybe – referring to @flackr’s description in #7475, option 5 – the Fixed Viewport (= Visual Viewport before zoom) would make more sense?

[flackr]

I think that giving the outermost viewport special abilities could be problematic for sites which use overflow scrollers for particular parts of their content (e.g. gmail doesn't have a scrollable root view) which would need to use frames I guess to establish viewport scrollers and get this behavior?

In my ideal world sticky would be able to offset based on the nearest scroller that has scrolls in the particular axis (e.g. top/bottom find the nearest overflow-y scroller). I recognize though that the situation we have though is overflow in one axis implies overflow in the other so it's not a simple change.

[css-meeting-bot]

The CSS Working Group just discussed [css-position-3] Making a stickypos in a scroller also see the viewport edges.

The full IRC log of that discussion

<dael> TabAtkins: An issue for a good while is when people use stickypos by default it sticks to viewport. Very useful. Stays on screen
<dael> TabAtkins: If you have a scrollable ancestor this stops happening. Stays in scrollport but no longer sticks to viewport. IF scrollport larger than screen you can scroll sticky thing offscreen even though intended to be always visible
<flackr> q+
<dael> TabAtkins: Request is for some mech to make sure a stickypos can see viewport edges even when it's not the closest scroller. Could go further to allow arbitary scroll containers, but important things are nearest scrollport and viewport
<Rossen_> ack flackr
<dael> flackr: Commented on issue, think viewport is too special case. I don't know if we have ability to have overflow:clip in one postion. That oculd be workable to make this composable so you can observe scroller scrolling you and not the one clipping you
<dael> TabAtkins: I don't think that solves. IN a scroller that can be scrolled vertically. You have a big table and want head to be sticky. Box of table is partially offscreen but you want thead to be sticky. Genuinely scrollable access is that thing you want to pay attention past
<dael> flackr: Concern is if we special-case viewport there's still a lot of cases where doc can't use viewport
<dael> TabAtkins: Agree. Hits on issue viewport has magic we can't reproduce. Talked in the past about being able to mark something as root scroller. Perhaps it's a matter of we should do that and it interacts well here
<dael> flackr: That would help
<dael> TabAtkins: I think you were a part of those discussion in the past, but that was years ago
<dael> flackr: It certainly stalled.
<dael> fantasai: Other prop in the issue was make it sticky to nearest scroller in the relevant axis. If you have only horz scroll something sticky in vertical axis sticks to next scroller up
<dael> TabAtkins: I thought use case listed in root is that or by what flackr mentioned
<dael> flackr: I think they are same. They could ignore nearest scroller if it desn't impact in that axis
<dael> fantasai: I feel like it's more flexible. Would it make sense?
<Rossen_> t-1 min
<dael> flackr: Tricky bit is non-scrollable direction is treated as overflow:hidden
<dael> fantasai: So can't be a scroll container
<dael> flackr: Could make non-scroll overflow:clip so it's explicitly not scrollable
<dael> flackr: Haven't fully thought if that works
<dael> TabAtkins: I don't think anything wrong with that. Clipping in 1 axis is weird visual stuff, but not if scrollable in other axis
<dael> TabAtkins: That might be it
<dael> flackr: Might be good in general to say something is clipped in one axis
<dael> TabAtkins: I want to do investigation, but that's a plausable approach
<dael> Rossen_: TabAtkins you want to do that and bring it back?
<dael> TabAtkins: Sounds good
<dael> fantasai: I wasn't expecting a resolution, but good to have progress

[tabatkins]

I want to investigate if we can use the existing 'clip' keyword for this (changing behavior) or if we need to add a new keyword that's like hidden-but-clip.

[jonjohnjohnson]

IMHO With the narrow (relative to current desired uses) initial intent of the sticky position scheme, I'm quite interested if we could expand the features being explored by houdini's layout-api &/or animation worklet to guide this native css features design?

See also #2496

[flackr]

I'd very much like to see clip in non-scrolling axis treat the box as not a scroll container for that axis for sticky position, scroll timelines and other cases where we use the nearest ancestor scroll container.

[phoenixsnake]

Can we do something like

.sp{
   sticky-origin: "sticky-parent";
}

.sp .sc{
   sticky-parent: "sticky-parent"; /* viewport | "user-defined: sticky-origin" */
}

[mantissa7]

Can we do something like

.sp{
   sticky-origin: "sticky-parent";
}

.sp .sc{
   sticky-parent: "sticky-parent"; /* viewport | "user-defined: sticky-origin" */
}

I would rather have a solution that is more generic that doesn't limit to just position: sticky.

.ancestor {
    container-root: foo;
}

/* .ancestor > .foo > .bar > .baz > .nested-child */
.nested-child {
    container-ancestor: foo;
}

[RheingoldRiver]

For cases where the sticky axis and the overflow axis are different, I would like a "just works" approach, so that there is no burden of knowledge here, and it is automatically set to viewport.

Where the axis agrees, I like this solution, and the general keyword that can be reused in other cases.