Re: [css-overflow] fragments vs paginate

On Sat, Mar 14, 2015 at 5:39 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
> 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.

I don't know if we really need a separate property for this.  It's not
an independent concern; it only applies when you're fragmenting.  We
could probably just (later) allow an <integer> argument after the
"paginate" keyword, so you'd write "continue: paginate 2;" rather than
"continue: fragments; n-up: 2;".

> 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.

This makes sense and I like it.

~TJ

Received on Wednesday, 18 March 2015 21:03:24 UTC