Re: [css-snappoints] 2/27 Updated ED

On Tue, Mar 4, 2014 at 11:57 AM, Matt Rakow <marakow@microsoft.com> wrote:

> >If we consider a slightly different example where the strip is scrollable
> via UA gestures as well as the buttons, I don't think you'd actually want
> to snap to container-sized boundaries; that would just annoy users who try
> to scroll a few more images into view and find they can't. Instead you'd
> want to snap to the margin-box of each image. Those buttons are just
> page-left/page-right controls and could be implemented just the same as
> they are today, although we might want to extend CSSOM ScrollOptions with a
> "snap" parameter so that the button event handler can opt into snapping
> when calling scrollBy so it snaps to an image margin-box edge.
>
> For any particular scenario we can weigh pros and cons of the details of
> the UX, but I think the meta-point here is that pagination is not an
> outlandish scenario to try and enable nicely since there are authors out
> there who are trying to build these sorts of widgets.  snap-interval() is
> able to do this pretty simply, but I'm definitely not opposed to
> alternative options.
>

CSSOM Views already lets apps easily scroll a container by a full page,
e.g. using
container.scrollBy(container.clientWidth, 0, {behavior:"smooth"});
This seems perfectly adequate for the Redfin example. I don't see what else
is needed under the rubric of "pagination".

[snip]
> >>What scenario were you examining in which this behavior worked well?
> >A list of images.
>
> These images were edge-aligned instead of center-aligned?


Yes.


> If there's a site/app/demo we can look at that tries to emulate
> direction-dependent snap points I think this might be helpful in
> illustrating the behavior and any benefits it may confer, and what
> scenarios this behavior is currently used for.
>

I don't have such a thing at the moment, unfortunately, but that's a good
idea. I'll try to carve out time to hack one up.

Again, I think the meta-point here is that altering behavior based on
> directionality of scrolling goes against the intent of the author for a
> variety of scenarios, and that there are real-world examples of UX that
> tries to achieve consistent alignment.  I don't see why snapping seems
> strange for spreadsheets -- Excel does this today for touch panning.  For
> text editors, Notepad++ on Windows is an example of one that snaps lines to
> the top edge (again, supporting touch panning as well).
>

I already pointed out that the spreadsheet behavior of jumping to
snap-points during the thumb/touch drag is not something most apps want, so
you'll want extra controls to opt into that if you want to support it.

>A scripted scroll to specific content probably should probably just ignore
> scroll-snapping entirely.
>
> The jump-to-N functionality is specifically targeted at jumping to a
> specific snap point (e.g. jump to page 10),


It's already easy to jump to page 10:
container.scrollTo(0, container.clientHeight*10, {behavior:"smooth"});


> but for general scripted scrolling we'll have to go through the use cases.
>  For most of the scenarios where we've seen mandatory snap points used,
> those scroll offsets represent the only "valid and sensible" scroll
> offsets.  Using the photo slideshow from Example 1 in the spec, it makes no
> sense to ever leave the user at a halfway point, so ignoring snap points
> for a script-scroll would look broken.  Additionally, as soon as the user
> interacts with any other modality, the snap points suddenly "remember" to
> take effect which is weird again.  But I'm sure there are other use-cases
> in which ignoring the snap points would be preferable.
>

I think we could leave it up to the script to ensure it only scrolls to
"valid and sensible" scroll offsets. This doesn't seem hard for authors to
do. But I wouldn't object if ScrollOptions adds a flag to control whether
to snap or not.

[snip]
> >Yes, but :-). It's easy to imagine situations when an author designs
> content for a large viewport with mandatory scroll-snapping because hey, it
> always works fine. But then someone tries to view that content on a small
> screen (or gets an unexpected large blog post, or needs to use a larger
> font-size than the author specified, etc) and it doesn't fit in one page,
> and suddenly chunks of it are completely unviewable. I think it's worth
> allowing the UA to intervene to prevent that.
> >I think we can be flexible here because there's a strong precedent that
> how scroll gestures work and how much they scroll is already highly
> UA-dependent.
>
> I think that sounds like a different concern from direction-dependent snap
> points.  Overall I think this thread raises a good issue that we need to be
> very careful in the spec about which aspects may be UA-dependent.  If we
> leave the functional behavior too open-ended then the feature becomes
> useless due to lack of interoperability.
>

Yes, it's a difficult balance. I would prefer to start with looser
constraints and tighten them up later if necessary, since that allows room
for UA experimentation ... plus we don't seem to have a consensus for what
the tight constraints should be ... plus we (or at least I) don't know what
properties authors will end up relying on for interoperability. The minimum
is that, given a horizontal or vertical list of elements, the UA will make
a best-effort attempt to avoid elements intersecting the edges of the
scrollport.

In that vein, I've edited
https://wiki.mozilla.org/Gecko:CSSScrollSnappingto be even more lax
:-). It now permits the choice of snappoints to be
independent of any gesture direction. (I still have to mention gesture
directions in one place, because I think it's important that gestures with
specific directions never result in scrolling in the wrong direction;
pressing down-arrow should never result in scrolling upwards.)

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