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

>From: rocallahan@gmail.com [mailto:rocallahan@gmail.com] On Behalf Of Robert O'Callahan
>Sent: Saturday, March 1, 2014 8:28 PM
>To: Matt Rakow
>Cc: www-style@w3.org
>Subject: Re: [css-snappoints] 2/27 Updated ED

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

This page should illustrate the intended behavior [1], try clicking the right/left arrows next to the filmstrip.  Perhaps I should add a similar example into the spec?

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

I think this makes too many assumptions about the type of content in play and snapping that the developer is going for.  What scenario were you examining in which this behavior worked well?

As a couple counter-examples:  Consider a spreadsheet application, which generally snaps rows/columns consistently to the top/left edge.  Similarly text editors will frequently align the top line with the top edge regardless of scrolling direction.  For non-edge-or-center-aligned content, it's common for the element to align instead with some other (probably fixed-position) element -- the Windows start screen is an example of this, where sections/columns attempt to align with the word "Start" in the top left corner.  Once we get into the suggested script APIs (e.g. jump-to-N functionality), I expect the developer will want a consistent and deterministic behavior for this API call regardless of the current scroll position (e.g. "jump to sports headlines" in a news application).

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

Special treatment of content based on its size would just be an additional layer of heuristics for a developer/designer to try to understand and control.  Scrolling behavior shouldn't suddenly change if the user resizes their browser window slightly.  Or in scenarios where element sizes are mixed (some larger than the viewport, others smaller) the scrolling behavior shouldn't change from element to element.  A deterministic behavior makes it much easier for developers and designers to get the precise behavior they want.

Thanks,
-Matt

[1] http://www.redfin.com/CA/Beverly-Hills/1091-Laurel-Way-90210/home/6822328

Received on Monday, 3 March 2014 19:04:58 UTC