[css-overflow] Top/bottom banners scrolling in and out as the pages scrolls (was:proposal: scroll-index (priority))

[jeysal]

Use case

Many pages consist of a full-width (and for example 64px height) header at the top and a full-width (and for example 100vh - 64px height) main content below it.
Many of those pages want the header to scroll out above the top of the viewport whenever the user starts scrolling down on the page, and scroll back in below the top of the viewport whenever the user starts scrolling up on the page. As far as I know, this is today implemented using JavaScript.

It is already possible to structure e.g. a grid layout to be able to scroll out a header.
The grid has 64px + 100vh height (y-overflowing the initial containing block), the header in its top row has 64px height, and the main content in its bottom row has 100vh height (and of course its content can y-overflow).

However, this is not sufficient to achieve the experience a user would expect.
If all scrollbars are in the top position and the user starts scrolling down in the main content, first the main content will scroll all the way to the bottom, and only once it can scroll no more, the top of the grid with the header is scrolled out of the viewport.
Likewise, if all scrollbars are in the bottom position and the user starts scrolling up in the main content, first the main content will scroll all the way to the top, and only once it can scroll no more, the top of the grid with the header is scrolled into the viewport.

There is another problem with the layout I described - there are two scrollbars, which does not look nice, but it seems this is already being worked on in css-scrollbars.

Proposal

Note: This proposal has been discussed by the CSSWG and classified as unlikely to be implemented. Therefore, if this use case is addressed to make it possible to implement this with pure CSS, it will likely be with a different solution.

I propose a scroll-index (resembling z-index in naming) or scroll-priority property that can be used to customize the order in which the user agent will try to scroll overflowing containers (whether using a scroll wheel or touch input) and takes precedence over the 'default priority' which is based on the structure of the elements. In particular, it can also be used to scroll a parent before its child when scrolling in the child.

This of course has interactions with things like overscroll-behavior, but none come to my mind that do not have an intuitive solution.

Notes

I suppose this suggestion fits best into the overflow module of all the existing modules, so I tagged it that way for now.

I apologize if this has been suggested before; I did not find relevant issues with multiple searches.

[fromaline]

@jeysal very interesting proposal to me 👍
Also, I'd like to point out, that with grid layout, the desired behavior couldn't be achieved if overscroll-behavior needs to be set to contain, for example, to control pull-to-refresh behavior.

[jeysal]

I suppose without a spec tag this is unlikely to get any traction, so I'll tag it as css-overflow which I think is most correct although it is of course always hard to tell for a new feature.

[jeysal]

@frivoal @fantasai tagging you (sorry if wrongly) because I believe you have been involved in css-overflow recently and I'd be interested in opinions on whether this solution could be a feasible, and the right solution for this very common use case.

[css-meeting-bot]

The CSS Working Group just discussed scroll-index.

The full IRC log of that discussion

<emilio> topic: scroll-index
<emilio> github: https://github.com//issues/5670
<emilio> florian: not my issue but I wanted to give it some attention
<TabAtkins> q+
<emilio> ... The use case is something we see on lots of websites, with a top banner that disappears but reappears if you scroll up again
<emilio> ... This author is thinking of this in terms of nested scrollers
<emilio> ... where your top banner is in a scroller outside the inner one
<emilio> ... we always prioritize the inner scroller
<flackr> q+
<emilio> ... but the author was proposing to prioritize the outer scroller, and only when that is exhausted scroll the inner one
<emilio> ... no strong opinion, there could be some parallels with overscroll-behavior
<emilio> ... just wanted to bring some attention to the issue
<emilio> TabAtkins: I find the use case good to address because lots of sites do this badly
<emilio> ... but I think this approach is not the way to go
<Rossen_> ack TabAtkins
<emilio> ... first this doesn't do what lots of sites do which is having a minified banner
<emilio> ... second, it seems very easy to screw up a page if you only test on desktop
<emilio> ... the current behavior is safer for that
<emilio> ... So I think the problem is good, the solution is bad
<emilio> ... we probably want another way to do this
<Rossen_> ack flackr
<emilio> flackr: I was going to point pretty much the same
<emilio> ... you only want to do this scroll priority inversion for the topmost scroller
<emilio> ... if you have nested ones then scrolling the header is probably not what the user intended
<Rossen_> q?
<emilio> ... so it seems a bit of a problematic solution
<emilio> Rossen_: sounds like the use case is well recognized, but the proposed solution is not
<argyle> agree with robert and tab
<emilio> ... I suggest to go back to the issue to discuss the solution
<emilio> florian: so the issue was proposing the solution, you're proposing to repurpose it right?
<emilio> Rossen_: sure
<emilio> florian: sounds good
<emilio> Rossen_: yeah, it seems like we should explore a good solution for this problem