W3C home > Mailing lists > Public > www-style@w3.org > December 2015

Re: [cssom-view][css-snappoints] scroll-snap and scrollTo/scrollIntoView interactions

From: Simon Pieters <simonp@opera.com>
Date: Fri, 18 Dec 2015 12:38:37 +0100
To: "Brent Fulgham" <bfulgham@apple.com>, "Robert O'Callahan" <robert@ocallahan.org>
Cc: www-style <www-style@w3.org>
Message-ID: <op.x9t7ynicidj3kv@simons-mbp>
On Fri, 19 Jun 2015 14:32:44 +0200, Robert O'Callahan  
<robert@ocallahan.org> wrote:

> On Fri, Jun 19, 2015 at 4:32 AM, Brent Fulgham <bfulgham@apple.com>  
> wrote:
>> The current specification  <http://dev.w3.org/csswg/css-snappoints> is
>> silent on what special scroll snap behavior should be triggered when a  
>> page
>> or element with scroll snap points is manipulated through  
>> window.scrollTo
>> or element.scrollIntoView.
>> Since many of the window.scrollTo/element.scrollTop/element.scrollLeft
>> uses are to manually animate scrolls, we probably do not want to trigger
>> snapping for these cases.
>> It’s less clear what to do for scrollIntoView. If aligning with the top  
>> or
>> bottom of a view does not align with any defined scroll snap points for
>> that view, should we adjust the positioning to match the closest snap  
>> point?
> I think scripted scrolling should not be snapped by default, but we  
> should
> extend the ScrollOptions dictionary with a 'snap' member.

Can you elaborate on what is needed in the API? What are the use cases?

 From simplest to least simple, I can imagine a single boolean flag to  
"snap", to being able to set all the things that you can set with the  
scroll-* properties also in the API. Or have an API to expose the closest  
snap point, so you can scroll to it. I'm not familiar enough with snap  
points to say what makes sense.

Simon Pieters
Opera Software
Received on Friday, 18 December 2015 11:39:12 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:55 UTC