Re: [css-break][css-overflow-3][css-regions][css4-ui] generalizing 'region-fragment' into a fragmentation primitive: a first step to solving multi-line ellipsis

On Feb 9, 2015, at 12:49 AM, fantasai <fantasai.lists@inkedblade.net> wrote:
> 
>> On 01/20/2015 08:13 AM, Florian Rivoal wrote:
>> [... lots of stuff ...]

I'm coming into this thread a little late. I just read Florian's long email (Not Too Long; Did Read), and I'm very interested in this. I've long wanted wanted this sort of Grand Unified Theory of fragments/overflow/pages, and it seems like we're getting closer now. 

I agree too that overflow:paged and overflow:fragments is almost the same thing. As I see it, the main difference is that with overflow:paged you only get to see one page at a time in the general case, though with something like 'pages-visible:2' you would have an open book spread, and with 'pages-visible:all' you could have the same thing as 'overflow: fragments'. Controls for turning pages would appear when not all the pages were visible, just like scroll bars do with other kinds of overflow. The UA would have a default animation for getting to the next page, and we'd want a property to be able to change that (page-change-animation: auto | push-vertical | push-horizontal | wipe-vertical |  wipe-horizontal | flip-horizontal | flip-vertical | turn-horizontal | turn-vertical). Then we don't really need need overflow:paged and overflow:fragments to be two different things. @page could apply to either one, through named pages. 

> Florian and I were bikeshedding the fragmentation property after-hours.
> (Briefly, this is a new property that is split off from 'overflow',
> taking along all the fragmentation-related values.)
> 
> Proposal so far is
> 
>  continue: auto | overflow | paginate | clone | discard | next
> 
>  overflow - content that doesn't fit overflows, according to 'overflow'
> 
>  paginate - content that doesn't fit paginates (formerly overflow: paged)
>             This creates a paginated view inside the element similar to
>             the way that 'overflow: scroll' creates a scrollable view.
>             Pages can be styled with @page rules. Print is effectively
>             continue: paginate on the root.
> 
>  clone - content that doesn't fit causes the element to copy itself
>          and continue laying out (formerly overflow: fragment)
> 
>  discard - content that doesn't fit is discarded at a fragmentation
>            break (generalized from region-fragment: break; on the
>            last region of a region chain)
> 
>  next - content that doesn't fit is pushed to the next region. If
>         there isn't a next region, it overflows. [Behavior could
>         have been to discard, but I think discarding anything should
>         be a very explicit behavior.]

Interesting. But it seems like unnecessary extra work to type 'continue: overflow; overflow: <whatever>'. If 'overflow' is a value that doesn't affect the other continue values, and the continue values mostly don't affect the overflow values, why not just come full circle by making these all values of the overflow property? That would give you something like this: 

Overflow: auto | scroll | hidden | visible | clone | next | discard

Maybe I'm missing something. You've probably thought it through more than I have. What would this give up? Is the problem with overflow-x and overflow-y? We already say that if you have 'scroll' for y, then x cannot be 'visible'. Could we just say that 'clone | next | discard' only applies to the block-stacking direction? So if you wrote 'overflow:scroll; overflow:clone;', the clone value would be thrown out for either overflow-x or overflow-y, whichever one was the inline direction, and you'd get scrollbars in that direction instead, due to fallback of that component value. 

Or suppose you have horizontal and vertical text in the same container, there might be good or bad breaking points in either direction. Wouldn't it be valuable if an element could clone fragments in two different directions? If so, then we could have 'overflow-inline' and 'overflow-stacking' component properties to help you choose how to deal with that. 

Either way, I think we should address the fact that there might be normal overflow in the inline direction that shouldn't be always clipped.

Received on Friday, 13 March 2015 01:47:53 UTC