Re: [css-sticky-scrollbars] feedback and variations on the concept

Hi,

> On 30 Jun 2015, at 16:22, Majid Valipour <majidvp@chromium.org> wrote:
> 
> I wonder if  there been any attempt to see if the same properties can be achieved using css scroll snap points. This specs is trying to provide a mechanism to control how scroll position is maintained when an scrolling element is resized[1]. Snap points spec has a similar mechanism where the scrolling container scroll offset remains at the snap point location after resize[2].

Yes, I've though about it, and chose to not dive into it just yet. My reasons were:

1 - snap-points is a much bigger spec addressing more varied use cases. Discussing this more narrow use case within the smaller sticky-scrollbar context should make it easier to iron out the differences between Tab's approach and mine without getting entangled on tangential issues caused by the broader scope of snap-points.

2 - snap-points, is still very much of a moving target, with both concrete issues filed against it and more vague but nonetheless valid concerns about the design raised (see comments here[1] by fantasai/dbaron/leaverou/me for example).

Neither of these mean that we should not eventually look at how this fits with snap-points, but it felt easier to me to work out exactly what we need for these use cases in one place, while giving snap-points time to settle down a bit in another place, and only then look at whether these 2 things should be fused, or whether some orthogonal building blocks can emerge.

> I think with some minor changes to the css snap points specification it should be possible to implement scroll-anchors using proximity snap points at appropriate edges of the scrolling area. I think we need these changes:
> 
>  • A way to specify snap points at the start and end of the container. There is already an issue in the spec to add something like this.
>  • scroll-anchor spec allows specifying the distance from which the anchoring comes into effect. Proximity snap points do not expose this but there is not reason why they shouldn't. For example something like scroll-snap-type: proximity 100px; can work well.
>  • Remaining at snap point after resize is mandatory only for mandatory snap points but optional for proximity ones. Perhaps this can be changed to make maintaining snap position after resize mandatory in both cases. (or expose separate snap types for user input scrolls and resize related scrolls)
>  • Florian's suggested modifications propose having different modes of anchoring such as glue or magnet. I think this can be achieved by having more extensive options for proximity snapping. The bonus is that these work the same for anchoring and other snapping behavior.

With the above reservations in mind, this makes sense to me. However, I am less sure how snap-points would cover:

- My "scroll-offset-anchor" property. Maybe it can just stay, it doesn't seem to interfere much with the rest. We'd need to tweak it to apply when you're not on any snap point instead of just not in the scroll anchor areas, but that's not a huge change.

- The preserve-context-around-the-caret aspect of "scroll-edge-behavior:glue", and the explicit "scroll-context" switch.

- Being able to snap both the beginning and to the end of a scroller, given that scroll-snap-destination only takes one value.
 
But again, I expect both sticky scrollbars requirements and snap-points details to change sufficiently that we will probably need to revisit all of that. We could probably work it out in one place, but I think it would significantly increase the overhead, at least of working out what is expected of sticky-scrollbars, and I am not sure I have the bandwidth to do a full review of snap-points just yet. I have various ideas regarding that spec, but I need time to sit down and think through them before I can send sensible feedback.

> This also means that we don't have to worry about creating potentially unexpected conflicts between snap-point and scroll-anchor guarantees (imagine a mandatory snap point that falls within range of a scroll-anchor!).

This is definitely something we will need to address. Whether it is by merging the two proposals or by making sure that they address orthogonal concerns seems a bit early to me.

 - Florian

[1] https://lists.w3.org/Archives/Public/www-style/2015May/0282.html

Received on Wednesday, 1 July 2015 11:53:25 UTC