Re: [css-snappoints] Feedback roll-up

On Tue, Jun 30, 2015 at 2:42 PM Matt Rakow <marakow@microsoft.com> wrote:

> 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?
>

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.


> 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).
>

I understand how making elements and repeat mutually can help with a
simpler syntax but are there no good use case for using both at the same
time? Perhaps a map that snaps at 100% intervals and city centers?

Also, any ideas on how we are going to handle specification of scrollable
area start and ends as snap points? I can see something like:
              scroll-snap-points-x: *start* repeat(100%) *end*

These snap points cannot be be mutually exclusive with either elements or
repeat. If that is going to be handled using a space-delimited syntax then
allowing the repeat in the mix should not make thing anymore complicated.


> 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.
>

Does that include Element.scroll{Top,Left}?

I would argue that there should be a way for programmatic scrolling to
evade "snap-points" when necessary. Perhaps evading snap points should be
default for programmatic scrolls with an option to opt in to snap points!
When an application uses a programmatic scrolls to scroll to a specific
offset it actually means to scroll to that offset and snap points should
not interfere with that. (Element.scrollIntoView and focus are the only
exceptions IMO)

Changing this behavior breaks long-standing developer expectations of
setting scroll offsets and it taking effect (See example below). It also
prevents some legitimate usecase such as animating scroll offsets.

function  scrollAndPosition(offset) => {
    $('scroller-with-snap').scrollTop = offset; // offset is adjusted to
snap which means scrollTop != offset
    $('absolute-element').top = offset; // ops! no longer positioned
correctly relative to scroller scroll offset.
}


> > 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.
>
> sgtm.


> > 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.
>

I am not aware of any concrete proposal offered at the f2f (my knowledge
are based on the meeting minutes). Perhaps fantasai can elaborate on this
more.

Majid