- From: Håkon Wium Lie <howcome@opera.com>
- Date: Fri, 16 Aug 2013 04:27:32 +0200
- 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?: http://people.opera.com/howcome/2011/reader/#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 Håkon Wium Lie CTO °þe®ª howcome@opera.com http://people.opera.com/howcome
Received on Friday, 16 August 2013 02:28:10 UTC