Re: [css-figures][css-multicol][css-overflow] Ten CSS One-Liners to Replace Native Apps

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.

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? 

 > 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 11:58:37 UTC