[css-snappoints][css-scroll-snap] Trapping snap coordinates from bubbling up to ancestor scrollers

Stating a new thread, because the previous discussion was quite fragmented:
   https://lists.w3.org/Archives/Public/www-style/2015May/0282.html (NYC 2015)
     Elements value is needed to trap scroll-snap contributions,
     for cases where author decides to remove scrollability.
   https://lists.w3.org/Archives/Public/www-style/2015Jun/0147.html (smfr)
     Less sure about this now..
     Also, nested scrollers issue -- need scrollers to trap snappoints
   https://lists.w3.org/Archives/Public/www-style/2015Jun/0159.html (majid)
     Separate capture from snapping
   https://lists.w3.org/Archives/Public/www-style/2015Jun/0376.html (rakow)
     Need some way to specify capture, maybe "elements"?
   https://lists.w3.org/Archives/Public/www-style/2015Jul/0035.html (majid)
     That doesn't prevent pass-through on scrollers. Need to be associated
     to nearest scrollable ancestor, but only snap if 'elements' is specified.
   https://lists.w3.org/Archives/Public/www-style/2015Jul/0457.html (rakow)
     * Scrollability is defined by 'auto' or 'scroll' computed value
     * Scrollability in an axis captures snappoints in that axis
     * Do we really need snapping to pass through per axis?
     * Priorities of nested snapping vs 2D snapping?

Basically the issue at hand is twofold:
   1. Specifying, as rakow explained in his last message, that scroll
      containers trap the snap point influences of their descendants, and
   2. Allowing elements that aren't scroll containers to trap snap
      points as well.

======  Issue 1 ======

  1. Specifying, as rakow explained in 0035, that scroll containers
     trap the snap point influences of their descendants, and

Wrt Issue #1, there were two proposals:
   A. Any scrollable ancestor (has 'overflow: auto | scroll') traps
      snap positions in both axes.
   B. A scrollable ancestor traps snap positions only in the scrollable
      axes, e.g. if it only has 'overflow-x: scroll', then it does not
      trap snap positions in the y-axis -- these can then be handled by
      an ancestor.
We don't think there's a very strong use case for the complexity of B--
if you have nested scrollers, you're not likely to align to items within
the inner scroller, but rather to align the inner scroller itself (which
is already possible). But don't feel strongly on this point if others
think the use cases for single-axis entrapment are strong.


====== Issue 2 ======

  2. Allowing elements that aren't scroll containers to trap snap
     points as well.

Wrt Issue #2, the solution proposed was to bring back the 'element'
keyword on 'scroll-snap-points-x/y'. We don't really think this
functionality is the best fit for scroll-snap-points-x/y, and would
prefer to re-use the 'scroll-snap-type' property, whose purpose is
after all to say whether or not an element is handling snap positions.

We can extend this property to apply to all elements, and if needed
add a special value equivalent to 'none' on scroll containers, but
that always traps scroll snap positions.

So, to summarize, the proposal is, if we want this ability, to not
add back 'elements', but instead make 'scroll-snap-type' apply to
all elements, and use it to trap descendant snap positions. The
variations are:
   A. The 'mandatory' and 'proximity' values trap snap points when
      specified on non-scrollers.
   B. A new 'trap' value traps snap points when specified on
      non-scrollers (and acts as 'none' on scrollers).
   C. The new 'trap' value *as well as* 'mandatory' and 'proximity'
      traps snap points when specified on non-scrollers.
   D. No change; snap position trapping is only through 'overflow'.

====== Issue 3 ======

note, there was a related thread with this point...

  3. Clarify that snap positions propagate through the containing
     block chain, not the box parenting chain, since abspos that
     escape a scrollable ancestor should obviously not affect it.
     https://lists.w3.org/Archives/Public/www-style/2015Jun/0148.html

This is just a bugfix in the spec, and imho needs no further discussion.

~fantasai and TJ

Received on Sunday, 25 October 2015 03:53:40 UTC