Re: [css-snappoints] Always snapping to a mandatory point

On Thu, Jul 30, 2015 at 7:35 AM, Matt Rakow <marakow@microsoft.com> wrote:

> The imperative API approach is not sufficient to satisfy the scenario; it
> just pushes the requirement to the author rather than the implementor.
> This is a requirement that implementors should take on rather than authors,
> because:
> 1) The author would need to understand and arbitrate between all input
> types and potential causes of content change to ensure they do not force a
> snap while the user is still interacting with the scroller, but does snap
> as soon as a rest state is reached.  If a new input type is introduced
> (e.g. the author didn't think about touch) then the control likely breaks.
> 2) The author currently has no way of knowing (esp. interoperably across
> browsers) when scrollbar-based scrolling has reached a steady state, e.g.
> when the user has "let go" of the scrollbar gripper.  Thus it's difficult
> to know when it's safe to call an imperative API to force a snap.
> 3) Even for input types that have better eventing, this will require the
> developer to register for all input events of all types to track when the
> scroller has reached a rest state.  Probably mutation observers as well
> unless they can constrain their control's layout to avoid reaching an
> invalid scroll offset.
> 4) The author does not know which snap point is appropriate to snap to
> without doing a large amount of work to track the currently snapped element
> and keep that up to date.  Consider example 1 from the spec [1], and
> suppose the user is currently viewing image 5 (thus the scrollLeft is
> 2000).  If the scroller and images are resized to 1000px wide (perhaps in
> response to the user maximizing their browser window) then image 3 is
> suddenly in view rather than image 5.  The developer would have had to
> track that image 5 was the currently snapped image, detect that something
> caused it to move, and called the imperative API to re-snap to the correct
> image.
>

These are good points, thanks.


> Actually, with regard to point #4, the invariant should be clarified in
> the spec that the *same* snap point must be snapped to (if it still exists)
> when content changes, not just any snap point.
>

What happens if that snap point ceases to exist?

When does this auto-snapping occur? On every layout? Including layouts that
occur during script execution?

What happens if layout changes to that the current snap point can't be
snapped to anymore because the container can't be scrolled far enough?

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn