[css-snappoints] Feedback roll-up

I've tried to cover the points raised in the last couple weeks below - please let me know if there's anything missing.

> So I think "nearest ancestor" needs to actually be worded in terms of containing blocks.
Makes sense -- do you have any suggestion for language here?  I saw the overflow spec makes reference to a "containing block chain" but with an open issue that the term is not defined [1].  If that term is usable I think something like "nearest ancestor in the containing block chain which is a scroll container"?

> I think what Robert is suggests prevents snap points crossing scroller boundaries (with the exception of overflow: hidden). However it is important to also avoid element snap offsets to cause unintended scrollers to suddenly snap. This can be resolved by separating snap point's contribution vs snapping.
I think if snap points are allowed to pass through to ancestors, then there needs to be a mechanism for capping their upper limit in order to facilitate nesting of snapping scrollers.  So far this is implicit since the nearest ancestor scroller is the only scroller which gets the snapping.  With an "elements" value I think we could specify that the snap points are only associated with a scroller which specifies "elements" rather than simply the nearest ancestor.  WDYT?

> The scroll snap draft[1] doesn't describe the interaction between snap-points-x/y and scroll-snap-coordinate on children
As Robert mentions, the sets of element-based snap points and snap-points-x/y are merged.  We didn't have a compelling case for this though, so if we add back the elements value then I'd rather go back to making the elements/interval options mutually exclusive for simplicity's sake (rather than introducing a space-delimited syntax for specifying snap points via multiple mechanisms).

> Also, it makes sense to have  horizontal and vertical snap offsets to be contributed separately.
> The "partial grid" behavior is interesting, but problematic when scrolling: a vertical scroll could yank you sideways to go to nearby snap point. So I'm not sure we want to do this.
At the Seattle f2f the partial grid behavior was called out as behavior that people were interested in -- I'd like to find a way to continue supporting this option, though I also get the scenarios for independently declaring each axis.  In particular partial grid seems useful for map-like scenarios using proximity snap points on major cities or landmarks.

> The current specification  <http://dev.w3.org/csswg/css-snappoints> is silent on what special scroll snap behavior should be triggered when a page or element with scroll snap points is manipulated through window.scrollTo or element.scrollIntoView.
This is covered in the description of snap types (since the behavior depends on the type) [2].  So the answer depends on whether you're referring to mandatory or proximity snap points.  In general there aren't "special" scrolling mechanisms that can evade snap points, so these (and all) scrolling mechanisms must snap for mandatory snap points and may snap for proximity snap points.

> I am not so certain about fixed and sticky positioned elements which are positioned relative to viewport and move as the document scrolls. I cannot think of any usecase where snapping to fixed position element makes sense and allowing it may result in unexpected scrolling behaviour (imagine an infinite scrolling page trying to snap to fixed position element!).  Perhaps we should disallow these.
I believe all UAs already prevent attempts to scroll fixed-position elements into view when the fixed-positioned element's containing block is the viewport that is being scrolled.  Makes sense though and I'll add a note that elements only must be considered as a candidate for snapping if there is a valid scroll offset which will allow them to snap.  Note that this isn't a blanket statement for fixed/sticky though, since fixed under transform are not fixed to the viewport, and position: sticky is satisfiable in many if not most cases.

> On that note, the last f2f meeting notes mention potentially reworking the spec to define snapping behaviour based on box alignments instead of the current coordinate alignment in order to handle responsive environments.
Thanks for pointing that out.  Snapping to the box alone isn't flexible enough to cover the full set of motivating examples detailed in the spec [3] but I'd be open to something that could live alongside the coordinate syntax.  Was there a proposal offered for this at the f2f?  Note that this overlaps with the existing open issue regarding selecting a different box for the purpose of scroll-snap-coordinate [4], and the requirement is probably satisfied by resolving that issue.

Thanks,
-Matt

[1] http://dev.w3.org/csswg/css-overflow/#overflow-concepts
[2] http://dev.w3.org/csswg/css-snappoints/#scroll-snap-type
[3] http://dev.w3.org/csswg/css-snappoints/#examples
[4] http://dev.w3.org/csswg/css-snappoints/#issue-cec53866

Received on Tuesday, 30 June 2015 18:42:30 UTC