Re: [css-snappoints] Early comments on Snap Points

On Tue, Oct 22, 2013 at 9:23 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> Some internal discussion pointed out that it's not clear what the
> behavior should be when there's no explicit snap-point at 0,
> particularly when scroll-snap-type is set to "mandatory".  I assume
> that there should always be an implicit snap point at the start and
> end of the element?
>

There are use-cases for having no snap-point at 0. For example the Twitter
UI where you scroll to the top to load more tweets, but releasing the
scroll gesture should snap scrolling down so the "loading" message scrolls
out of view. So I would make sure we can do that, although you usually do
want snapping positions at the top and bottom of the scrolled content by
default.

Another use-case is the mobile Simfy app's album screen. There's an album
image at the top of the page with a list of songs below it. Scrolling snaps
the top of the viewport to either the top of the image or anywhere below
the image (i.e. when you're scrolling through the song list, there's no
snapping at all). For this, we could let scroll-snapping target continuous
regions as well as discrete edges, extend scroll-snap-points-x/y to support
continuous ranges, and extend scroll-snap-edge from my proposal with values
like "border-box".

I think the terminology "snap points" can be misleading. You don't snap to
Cartesian points, you snap to horizontal or vertical lines/edges. I suggest
renaming everything to not refer to points. "Positions" might be better.

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w  *
*