W3C home > Mailing lists > Public > www-style@w3.org > March 2015

[css-overflow] fragments vs paginate

From: Brad Kemper <brad.kemper@gmail.com>
Date: Sat, 14 Mar 2015 17:39:45 -0700
Message-Id: <FF1704C5-D5C1-4D6F-A99D-0DD094036685@gmail.com>
To: www-style list <www-style@w3.org>, Florian Rivoal <florian@rivoal.net>
In the new overflow draft the values for 'continue' include 'fragments' and 'paginate' (similar concepts were in the previous draft too, for 'overflow'). It also mentions that there should be a property to display N pages at once. 

Brad Kemper
I would argue that this property (let's call it 'n-up' for now, as a number of pages "up" in the printing industry means they are printed on the same sheet) should be the switch that turns 'fragments' overflow into a paged presentation. The value on the first item of the fragment chain would apply to fragments of the chain (region chains too). 

So, 'n-up: all' would give you all the fragments, as described for 'continue:fragments'. 'n-up: <number>' would provide page turning controls to access pages that went beyond that number. For instance, the last visible page could have a "next page" widget and the first visible page could have a "previous page" widget. That would be up to the UA (maybe with some hooks to replace the default with a JavaScript version). 

If you wanted side-by side pages, you could style the fragments with 'display: table-cell' or whatever. 

The only other thing that really differentiates onscreen pages from general fragment overflow is that they should pay attention to @page. That could also be triggered by ’n-up’ not being ‘all’ on a fragment flow. Or maybe by limiting onscreen @page use to named pages applied to overflow fragment chains and region chains. Or maybe we could let @page be proceeded by selectors, to let it apply to the selected fragment chain.

For print media, ’n-up’ would have no meaning. 

OR… maybe ’n-up:1’ on the root would mean to print one root fragment per output physical paper page (or PDF), and larger values would shrink the root fragment to fit the required number of root fragments on the output paper page. If that were the case, the AU print style sheet would have ‘continue:fragments; n-up:1’. If the @page used had a non-auto ’size’, then that size would be used instead of shrinking to fit, and the UA would attempt to fit them on the (probably large format paper) page, tiling to multiple pages if needed.
Received on Sunday, 15 March 2015 00:40:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:05 UTC