[css-snappoints] Associating element snap points with a scroller

>From Majid:

> Well, that does not prevent snap points to pass through to ancestor even
> when the intermediate scroller has "overflow:scroll". This fails to address
> the original issue raised by Simon. Original example below:
> 
> <div id="outer" style="overflow:scroll; scroll-snap-points-x: elements;>
>     <div id="intermediate" style="overflow:scroll">
>         <div class="inner" style="scroll-snap-coordinate:50% 50%"></div>
>         ... more ...
>     </div>
> </div>
> 
> With your suggestion the inner snap points will be associated with outer
> which means that when intermediate is scrolled, outer need to snap which is
> undesirable.
> 
> Snap points should still be associated to nearest ancestor with non-hidden
> overflow but only ever snapped to if scroller has 'elements'. This allows
> them to cross boundaries when reasonable with an implicit cap. At the same
> time it prevents them to cause snapping on unintended scrollers.

Hm, I think maybe I misinterpreted the feedback.  It sounded to me initially that the request was to add the capability for snap points to cross scroller boundaries by explicitly setting their target with the "elements" value, but I think that's not what's actually being requested.  Let me try rephrasing and see if I have this right:

1) The initial concern was that overflow: auto can make it ambiguous which scroll container a snap point will associate to, as currently written.  David Baron suggested simply always calling "overflow: auto" a scroll container regardless of whether a scrolling user interface is presented or not [1].  Simon counter-proposed bringing back the "elements" value to resolve the ambiguity.  This would imply that snap points could cross scroller boundaries, if the nearest ancestor scroller did not specify "elements" but a further ancestor did.  The WG resolved on that approach.
2) Simon later emailed the mailing list with reservations about letting snap points cross scroller boundaries [2].  Rob proposed sticking with "nearest ancestor" but splitting X/Y axes with nested 1D scrollers in mind [3].
3) Majid elaborated on Rob's proposal with more independently controllable X/Y properties (e.g. scroll-snap-coordinate-x/y) [4].  Simon pointed out that this might preclude support for a partial grid of snap points (at least without some more thought on the API surface) [5].

If I've got my head straight now, I think here are the things we agree on:
1) The presence/absence of a scrollbar controlling which element receives a snap point in the overflow: auto case is confusing.  Overflow: auto should qualify as a scroll container regardless of whether a scrollbar is actually present.
2) A snap point should only contribute to the nearest ancestor scroller, at least on a per-axis basis.  It should not be able to bypass the nearest ancestor scroller and associate itself with a more-distant ancestor.

Things I'm less clear on:
1) What's the likely construction of a nested 1D scroller scenario -- would the author really want to snap the outer scroller against elements contained within the inner scroller(s)?  For something like the Netflix UI (effectively a series of horizontal 1D scrollers in a vertically scrollable page) I would expect the vertical snapping to be done with snap points on the horizontal scrollers themselves, rather than the elements.
2) Supposing there is a sensible construction that would work best with snapping the inner contents against the outer scroller, and supposing that we have to make a tradeoff of that functionality against the partial grid of snap points as Simon suggests, how do folks feel about the relative rank of those two capabilities?  Partial grid seems more interesting to me on the surface (as mentioned previously for map scenarios) but would like to see what opinions people have.

If we don't think snapping an outer scroller against the inner scroller's elements is an interesting scenario, then I think the update is simple -- just make the change David Baron initially proposed of "overflow: auto" is always a scroll container, and leave out "elements".  If we do want to support that construction then I think it probably ends up something along the lines of what Majid proposed.

Does that sound right?  Apologies for the confusion :-/

Thanks,
-Matt

[1] https://lists.w3.org/Archives/Public/www-style/2015May/0282.html
[2] https://lists.w3.org/Archives/Public/www-style/2015Jun/0147.html
[3] https://lists.w3.org/Archives/Public/www-style/2015Jun/0152.html
[4] https://lists.w3.org/Archives/Public/www-style/2015Jun/0159.html
[5] https://lists.w3.org/Archives/Public/www-style/2015Jun/0170.html

Received on Thursday, 30 July 2015 00:13:40 UTC