Re: CSS properties for snapping during scrolling

On Fri, Aug 16, 2013 at 12:28 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Thu, Aug 15, 2013 at 5:20 PM, Robert O'Callahan <robert@ocallahan.org>
> wrote:
> > Could we support both physical and logical properties and values here? I
> > think we could. So scroll-snap-edge values could be "none | [ left ||
> > margin-left || top || margin-top || inline-start || margin-inline-start
> ||
> > block-start || margin-block-start ]". (I've wondered whether
> > "end"/"right"/"bottom" values would be useful as well, but I haven't
> though
> > of a need yet.)
>
> I see no reason why you *ever* want physical snapping.  When you would
> want an element to snap in the block axis in a horizontal language,
> but in the inline axis in a vertical language?  That's what "vertical"
> means, after all.
>

In the FirefoxOS home screen use-case, we will never want the home screen
to scroll vertically, and I don't think we would reverse the order of the
home-screen pages in RTL languages either. In such cases, having to use
logical properties is just unnecessarily confusing.

Logical properties make sense when you're talking about text. Sometimes we
aren't.

>> scroll-snap needs an additional value that abruptly jumps between the
> >> snap points, rather than allowing smooth scrolling and then adjusting
> >> to a snap point (this is used by things like spreadsheets).
> >
> > Does this make sense for touch panning? I kinda doubt it does. Maybe
> instead
> > whether we abruptly jump between snap points should be up to the UA and
> > depend on the scroll mechanism?
>
> Yes, of course it makes sense.  There's no difference between a touch
> pan, a trackpad pan, and a mousewheel, but all three of those trigger
> this sort of behavior in, say, Google Spreadsheets.
>

I'm not sure if that' s intentional or just an artifact of the
implementation.

Usually with touch-based panning you want the illusion that the content is
moving with your finger. Jumping one row or column at a time in a
spreadsheet would ruin that illusion, and I haven't personally seen such
behavior intentionally implemented in a touch device.

Mousewheel scrolling, keyboard scrolling, and clicking on scrollbar arrows
are all inherently discrete, so it makes sense for them to jump to the next
snapping point --- although the UA could and probably should still animate
the jump. Scrollbar thumb dragging is somwhere in between.

Can you get a Google Spreadsheets UX designer to go on the record saying
they really want scroll offsets to instantly jump across cells during touch
panning?

>> I'd add an additional property for setting explicit snap points in
> >> addition to the implicit points coming from the children, probably
> >> with a repetition syntax so you can set up a snap point every 100px or
> >> whatever.
> >
> > That makes sense.
>

Actually, what are the use-cases for this? I can't think of any that
wouldn't work better using scroll-snap-edge on descendant elements.

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