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

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

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

Correct that it currently doesn't work with other input -- I'm just using this as an example of the design paradigm, not the coding pattern.

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

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

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

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

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

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

Thanks,
-Matt

Received on Monday, 3 March 2014 22:58:27 UTC