Re: [css-overflow] processing model of continue:discard

On Mar 19, 2015, at 3:18 AM, Florian Rivoal <florian@rivoal.net> wrote:

>> So that would be this: 'breaks: auto | none | clone | discard'.
>> 
>> 'breaks: none' would mean don't break, and you will have overflow if you didn't already. 'breaks: discard' would mean discard anything after the break.
>> 
>> Maybe 'break-target' would be better?
> 
> I quite like this,

😊

> although I am not too sure between the 2 property names. 'breaks' sounds like a good fit with ''none'', while 'break-target' goes well with auto and clone. As for discard, you're neither discarding the breaks not the break targets.

I had the same sort of thoughts, though I thought 'break-target: none' still worked pretty well. With no target for the content after the break to go to, it would just stay in the same box. Agreed that 'discard' doesn't fit with either property name quite as well, but seems pretty clear nonetheless. If we had 'break-remainder' (as in, what to do with the remainder of the content after the break), it would work for most of the values, but would be confusing with 'none'. But I suppose that could be 'break-remainder: keep'. Still not quite right for 'break-remainder: clone' though, because that makes it sound like you are cloning the content instead of the box. 'clone-box'?

> Despite that, I think we're getting closer.
> 
>> I didn't include 'page' or 'paginate' for values, because I think that the same as 'clone' but with fewer fragments shown together. There should be a different property to say how many fragments are shown (1 "page", or a right and left "page", or all the fragments), with controls for paging through them when some are hidden (kind of like the roll scrollbars play for overflowed content).
> 
> We don't have a model for how page should work

Not sure how much about that to keep in this thread, but the model in my mind is this (using property names and values from the current version of the draft):

1. Paginate is the same as fragments, with the primary difference being that most of the fragments are not visible until some mechanism (buttons or gestures or slider or whatever) is used to access them. Therefore, we shouldn't pretend that the way they handle breaking into new boxes is different, we just need a way to add the extra effect of hiding the fragments that represent hidden pages, and thus triggering paging controls. 

2. The clearest way to do that is via a clearly-named property that lets you decide how many pages to have "open" and visible at a time (usually 1 or 2 for looking like traditional media). This could be applied to any chain of fragments, including region chains, regardless of where the region boxes come from. 

3. We have lots of ways to lay things out and style them, and don't need anything special for that here. So if you want it to look like 2 pages side-by-side, you could do something like this for the fragment boxes: { display: table-cell; width:40em; height: 60em; border:1px solid; box-shadow:2px 2px 1px rgba(0,0,0,0.4); }. 

4. Printed paper or PDF output pages are 'continue: fragments', because they do not need a UI for advancing through hidden pages. They do need @page access though. 

5. @page access could be opted into for any fragment chain (and is non-optional for print media). Perhaps 'n-up' triggers it, in addition to hiding fragments and creating paging controls. Or perhaps any region chain with an n-up number would opt in using existing named pages mechanism only. Or perhaps something else that doesn't break existing region use. 

6. It would be good to have a property to control the animation of transitions between on screen pages that were created through 'continue: fragments'. 

7. N-up could be useful in print media for actually printing multiple web pages on the same sheet (or virtual sheet that is tiled).

Anything missing?

Received on Thursday, 19 March 2015 20:57:30 UTC