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

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

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

AFAICT the strip is not actually scrollable using any UA gestures, but only
using those buttons, so scroll snapping isn't relevant here.

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.

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

A list of images.


> As a couple counter-examples:  Consider a spreadsheet application, which
> generally snaps rows/columns consistently to the top/left edge.


Spreadsheets are weird; they behave like no other scrollable content. For
example, when you drag the scrollbar thumb, you can't even temporarily get
the topmost cell's top edge to misalign with the viewport top --- whereas
with all other content I've ever seen, even content that snaps, snapping
happens after the gesture ends so you don't lose the sensation of the
content tracking the thumb (or more importantly, your finger, for touch
interfaces). For this reason, on the Web spreadsheets are implemented using
crazy hacks where the spreadsheet content is in an element that's not
scrolled directly by the scrollbar. (I've always wondered why spreadsheets
behave this way; it doesn't seem to add any usability, and it makes
thumb-dragging or touch-dragging scrolling feel worse. I suspect it's just
tradition.)

I assume you don't intend CSS scroll-snapping to work for spreadsheets
(unless we add more customization controls), since the spreadsheet behavior
is inimical to normal touch behavior.

Similarly text editors will frequently align the top line with the top edge
> regardless of scrolling direction.


I can't find any text editor on my Linux desktop that does this. Most of
the editors I can find (gedit, LibreOffice, Firefox, Chrome, Eclipse, GTK2)
do no snapping at all. A couple (emacs, gnome-terminal) adjust the window
size so that a whole number of lines always perfectly fit.

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

A scripted scroll to specific content probably should probably just ignore
scroll-snapping entirely.

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

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.

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