W3C home > Mailing lists > Public > www-style@w3.org > July 2014

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

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>
Message-ID: <2BFAA617-4E93-4520-96BE-FE8163853FB3@adobe.com>

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

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