W3C home > Mailing lists > Public > www-style@w3.org > August 2013

Re: CSS properties for snapping during scrolling

From: Håkon Wium Lie <howcome@opera.com>
Date: Fri, 16 Aug 2013 04:27:32 +0200
Message-ID: <21005.36372.563331.423375@gargle.gargle.HOWL>
To: robert@ocallahan.org
Cc: Morten Stenshorne <mstensho@opera.com>, www-style <www-style@w3.org>
Robert O'Callahan wrote:

 > On Thu, Aug 15, 2013 at 9:39 PM, Morten Stenshorne <mstensho@opera.com>wrote:
 > > For such a use case, have you considered paged overflow [1][2]?
 > >
 > Paged overflow would work for that one use case but it's more work to
 > implement and less applicable to other similar use-cases (when multiple
 > items fit into the container), so I don't want to go that way.

To me, it seems that paged overflow is a subset of the MS proposal. In
paged overflow, one would write:

  .container {
    overflow: paged-x;

while in the MS proposal you would write:

  .container {
    overflow-x: auto;
    overflow-y: hidden;
    -ms-scroll-snap-type: mandatory;
    -ms-scroll-snap-points-x: snapInterval(0%, 100%);

So I don't understand why it's more work to do paged overflow. 

Perhaps you are thinking about the associated API?:


I think these are necessary in order to create "bulleted" page
indicators. In order to replicate these commonly used experiences from
native apps, we need to support interaction types beyond scrollbars.
Therefore I think there's a value in thinking of the problem as
discrete pages rather than as snapped scrollbars. I can, however, see
use cases for non-paged snaps. For example, a novel may be presented
in a two-column layout on the screen, and one may want to move to the
next column (instead of the next page) with a gesture.

What use cases did you have in mind?

              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Friday, 16 August 2013 02:28:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:33 UTC