- From: Sylvain Galineau <galineau@adobe.com>
- Date: Thu, 24 Jul 2014 14:27:39 +0000
- To: Håkon Wium Lie <howcome@opera.com>
- CC: "<www-style@w3.org>" <www-style@w3.org>
On Jul 24, 2014, at 4:58 AM, Håkon Wium Lie <howcome@opera.com> wrote: > Sylvain Galineau wrote: > >>> I've written a piece on how CSS can reproduce functionality currently >>> used in native apps. >>> >>> http://alistapart.com/blog/post/ten-css-one-liners-to-replace-native-apps >>> >>> The sample code is from CSS Figures and CSS Multicol, with a dash of >>> CSS Overflow: >>> >>> http://figures.spec.whatwg.org/ >>> http://www.w3.org/TR/css3-multicol/ >>> http://dev.w3.org/csswg/css-overflow-3/#overflow-properties >> >> This reminded me of something I've been meaning to bring up regarding the overflow >> paged-* values. >> >> I think of 'paging' as the combination of two controls: >> 1. In what direction does content overflow? To the side? Up/down? > > Yes. > >> 2. What is the unit of scrolling/overflow navigation? 1px? One viewport's dimension worth? >> One at a time of the author's set of image elements? >> >> The overflow property seems a reasonable place to define the former; scroll snap points [1] >> are meant to specify the latter e.g. scroll-snap-points-x: repeat(100vw) scrolls one viewport >> width at a time. > > In my mind, the page has been the unit. So, when the user goes "next" > (by tapping, or making a swiping gesture, perhaps), the current page > disappears and a new page appears (perhaps with some stylable page > transition in between). However, there are situations when it makes > sense to page/scroll/pan smaller unites. You mention images: if the > screen is wide enough to show two images, it would make sense to > page/scroll/pan half a screenful. Likewise, if an e-book uses two > columns to display some text, it would make sense to page/scroll/pan > one column at a time. Yes. Ultimately, the author needs control as to how much goes into a page. (And that page may not be full screen) > > Spanning elements complicates this somewhat -- you may have headlines > or images that span several columns. If a swiping gesture results in > movement by one column, headlines or images will be only partially > visible. Which may not be a big problem, you can always go back. > > Another issue would be that users must contribute more gestures. For > example, it would require three times as many gestures to read a book > if you limit movement to one column in a three-column layout. > >> I *believe* this split is the direction we're headed but it's not 100% clear from current >> specs (or your ALA article). >> >> Another way to ask is, if the author specifies the following: >> >> overflow: paged-x; >> scroll-snap-points: repeat(50%); >> >> Does it mean: >> >> A) Fragment the content one container (viewport?) width at a time; but scroll one half container >> forward/backward. >> >> ....or does it mean: >> >> B) overflow content shall go to the right (or left); prev/next page gestures move half a container worth >> >> I'm assuming B but I can't tell from the current early stages of those drafts. > > Is the difference between A and B that A fragments while B overflows? B is just regular overflow - with a choice of which way the overflow goes - but with fine-grained scrolling control; in A the overflow property generate breaks at some boundaries first i.e. so that content doesn't straddle the edge, similar to print page breaks. I *believe* you think of overflow:page-* as doing A. > >> These two things seem like they interact though. Interesting in hearing about how. >> >> [1] http://dev.w3.org/csswg/css-snappoints/ > > -h&kon > Håkon Wium Lie CTO °þe®ª > howcome@opera.com http://people.opera.com/howcome
Received on Thursday, 24 July 2014 14:28:10 UTC