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

Thanks for your reply.

On Sat, Mar 1, 2014 at 7:43 AM, Matt Rakow <marakow@microsoft.com> wrote:

> From: rocallahan@gmail.com [mailto:rocallahan@gmail.com] On Behalf Of
> Robert O'Callahan

>I have the following additional issues:
> >Section 5:
> >Are snap-interval and snap-list actually needed assuming we can snap to
> element boundaries?
>
> snap-interval is particularly useful for pagination scenarios, where there
> may not be a single element that spans the height/width of the scroller.
>  The example we used at the f2f was a "filmstrip" style viewer, where
> images are viewed N at a time.  Redfin.com's property listings are a good
> example of this.


URL? I can't seem to find the part of Redfin.com you mean.

An example construction might look like:
>     <div style="width: 500px; scroll-snap-points-x: snap-interval(0,
> 100%)">
>         <img style="width: 100px;">
>         <img style="width: 100px;">
>         ...20 more images...
>         <img style="width: 100px;">
>     </div>
>

What exactly is the Web developer trying to achieve here? I mean, simply
preventing users from scrolling images 2, 3, 4 or 5 to the top of the page
doesn't seem like a useful goal. My guess is that they're trying to make
small touch swipe gestures scroll a page at a time. Is that right?

If so, I'm not sure scroll snapping is the right way to achieve that. For
example, if it's a desktop browser and there's a horizontal scrollbar, the
above example would make clicking on the left/right scrollbar buttons
scroll a page at a time, while clicking on the scrollbar track also scrolls
a page at a time, and it's impossible to drag the thumb to show (e.g.)
elements 3,4,5,6 and 7. That seems like a usability regression.

>How do we handle the case where elements have different widths and some
> gestures want to snap to the left edge and others to the right edge (or
> top/bottom edge respectively)?
>
> The snap-axis and snap-coordinate combination already allows snapping to
> any edge regardless of element dimensions, though this does not vary based
> on details of the gesture.  Varying based on gesture is undesirable -- the
> snap point's location needs to be determined based on the content, not on
> how it was reached.
>

I don't agree. We've played with prototypes of scrolling through a list of
items where the items vary in size, the viewport height is not a multiple
of the item height, and several items fit in the viewport. In that
scenario, when you're scrolling down on a big screen, we prefer snapping
the bottom edges to the bottom of the viewport, because typically your eyes
are looking there for the new items coming into view, and snapping the top
edges is worse than not snapping at all.

Similarly for snapping elements that are larger than the viewport (say,
> large sections of a long article), it's desirable to ensure that the
> section header and initial content snaps into view.  If this varied based
> on direction, then scrolling the opposite direction would only get the last
> few paragraphs of the section in view, with no header or other context
> provided.  The user would have to scroll past the section and back down
> again in order to view the section header.
>

This is a good point. When snapping is being used to ensure we display
whole items instead of partial items whenever possible (which I think is
usually the goal), single items that don't fit in the viewport need special
treatment. For such items you probably want to allow snapping of both the
top edge to the top of the viewport and the bottom edge to the bottom of
the viewport (not at the same time of course). The latter makes it easier
to see a full viewport-ful of the end of the item before you move to the
next one. You probably also want to disable mandatory snapping while such
an item is the only thing visible in the viewport, otherwise you can get
into situations where the middle of the item is unviewable.

It's easy for our proposal to accommodate all these behaviors. We'd just
need to delete some of the constraints on the UA that are currently listed
on the wiki page.

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