[css-position][css-sticky] Should overflowing sticky element continue scrolling until meeting opposite offset?

[jonjohnjohnson]

If a sticky element happens to be larger than it's scrollport and offset in the scrolling dimension, I'm guessing the lion's share of intent isn't what is represented in the spec and implementation. It currently sticks to the designated edge, continuing to hide/clip the overflowing edge until scrolling all the way to the other side of it's containing block.

Examples -> http://jsbin.com/fajosud/2

This particular case where a sticky element overflows its scrollport isn't exactly underspecified as much as its behavior just doesn't break or provide much utility.

I'd imagine it more useful if when scrolling from an elements sticky edge, it continues to scroll until meeting its opposite offset value, then sticking, if its height plus offset value "overflows" the opposite edge of the scrollport.

[jonjohnjohnson]

Current, left. Proposed, right.

animation updated per #2558 (comment)

Scrolling element is black. Sticky elements with top box offset are red. Containing block is grey. In current, you can see how the bottom of an overflowing sticky top element would be clipped for the duration of scrolling its containing blocks height, which just doesn't seem useful?

[SebastianZ]

If I am not mistaken, an example for how it is expected to behave is the sidebar on https://mein-mmo.de/, which is powered by the Theia Sticky Sidebar for WordPress.

One point of this implementation is that it considers the direction in which the scrollport is scrolled. I.e. when the scrollport is scrolled down, the element's upper edge sticks to the top of the viewport and when the scrollport is scrolled up, the element's lower edge sticks to the bottom of the viewport.

Sebastian

[smfr]

I think the existing behavior feels more natural.

[SebastianZ]

The main issue with the current behavior is that the part of the element that is outside the viewport is not visible until you reach the end of its container. This behavior is not intuitive to some people according to the feedback on some user testing we conducted on the aforementioned site.

Sebastian

[SebastianZ]

In other words, the visibility of the parts of a sticky element that are outside of the viewport depend on the size of its container. I.e. the bigger the container, the longer the user has to scroll to see the rest of the element.

This behavior may be desired in some use cases, though as @jonjohnjohnson wrote before, I believe the more natural UX is that you don't have to scroll over the whole container to see the element's contents.

Sebastian

[SebastianZ]

There's another jQuery Plugin allowing you to do this called Sticky-Kit and there is obviously a demand for it:

https://stackoverflow.com/questions/18358816/sticky-sidebar-stick-to-bottom-when-scrolling-down-top-when-scrolling-up

I've created a simple example comparing the current implementation with the one which sticks to the opposite side:
https://jsfiddle.net/SebastianZ/kb9zdvqe/ (left: sticking to opposite side, right the current behavior)

If this proposal gets picked up, there are different solutions how to spec. this:

1. Change the current behavior to the proposed one.
2. Add a new position keyword (like sticky-inner-scrolling) for it.
3. Define a new property (e.g. sticky-behavior: non-scrolling | scrolling) that defines the behavior when position is sticky.

The last two have the advantage of allowing both behaviors. The names are obviously to be bikeshedded. Personally, I tend to option 3.

Sebastian

[jonjohnjohnson]

@smfr @hober Can you provide any examples that show how the current behavior shows a natural feeling? You are the first to share this view with me after asking many folks about the current behavior.

@SebastianZ AFAICT what you are describing is something above and beyond sticky, and more akin to the chromium devs search for "hidey bar" solutions better achieved through houdini mechanisms?

• https://github.com/w3c/css-houdini-drafts/blob/master/scroll-customization-api/UseCases.md#hidey-bars
• https://github.com/w3c/css-houdini-drafts/blob/master/scroll-customization-api/UseCases.md#re-targeting-scrolling
• https://www.webcomponents.org/element/@polymer/app-layout/elements/app-header

I personally like to think of that as more "swinging" behavior, and though a "hidey bar" is most thought of as a nav bar that doesn't in fact overflow it's scrolling context, the swinging behavior is the same where scroll direction is "retargeted" to the placement of this "sticky" element between its constrained (overflowing) edges.

But concerning the current spec language, I am fairly certain it was never written with overflowing sticky elements in mind and what we have is just what has emerged, not providing very much utility.

PS We need a new css-position editor. :(

[SebastianZ]

@SebastianZ AFAICT what you are describing is something above and beyond sticky, and more akin to the chromium devs search for "hidey bar" solutions better achieved through houdini mechanisms?

If I understand the "hidy bar" use case correctly, it is about an element being shown at the top or bottom of the viewport, which is shown or hidden depending on the scroll direction. So, something similar to the bar that is shown here on GitHub when scrolling down (except that it doesn't depend on the scroll direction). That is a totally different use case.

I thought my use case would be the same as yours, i.e. overflowing elements stick to the opposite side. If not, could you please create an animated graphic like you did above showing how the behavior is when scrolling up again?

Sebastian

[jonjohnjohnson]

Could you please create an animated graphic like you did above showing how the behavior is when scrolling up again?

Above animation updated. Please, if you have not already done so, see the examples I linked in the original filing, scroll the examples up and down.

Examples -> http://jsbin.com/fajosud/2

The second scroller in the example shows my proposed behavior with description, whether scrolling down or up. And exactly like the title of this post refers to, it's only about an overflowing sticky element being able to continue scrolling until reaching the opposite edge/offset inside the scrollport.

In my original post I say...

I'd imagine it more useful if when scrolling from an elements sticky edge, it continues to scroll until meeting its opposite offset value, then sticking, if its height plus offset value "overflows" the opposite edge of the scrollport.

I'm just guessing that movement relative to scrolling direction is outside the bounds of what sticky, a position scheme, wants to handle and is more something that plays well into houdinis scroll/animation timeline features.

However, I definitely agree with you that providing a simpler solution for swinging/hidey behaviors in the web is needed. We see a plethora of native and web UI using these techniques and many devs providing solutions like the "sticky kit" you linked. A few years ago I even made my own plugin to provide hidey bars as well as sidebars like the "sticky kit" that use the same underlying mechanisms.

https://assets.jonjohnjohnson.com/scripts/swingy/

Hidey bars, which are often seen as both headers and footers, moving with or against the scrolling direction, are seen all over the ui landscape. So regardless of placement/size, they are simply blocks of content which move in relation to their scroll direction between constraints(offsets), calculated from both the geometry of itself and scrollport? To me that describes "hidey bars" as well as the "sticky kit" example. It just is that the they have different offsets with which to adhere.

[bashidagha]

A good library for workaround:
https://www.npmjs.com/package/react-sticky-box