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 09 Feb 2015, at 09:49, fantasai <fantasai.lists@inkedblade.net> wrote:
> 
> On 01/20/2015 08:13 AM, Florian Rivoal wrote:
>> [... lots of stuff ...]
> 
> 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.]

I've started specifying this up in http://dev.w3.org/csswg/css-overflow/#fragmentation.

I initially wrote the spec as suggested above way, except I used ''fragments'' instead of ''clone'' for now, for better consistency with the rest of the terminology in the spec. I might revisit that later, but that's not what I want to focus on right now.

However, when working out what these various values compute to in difference cases, I realized that ''next'' and ''auto'' end up meaning the exact same thing in all cases (please check the spec for details). I didn't think it made sense to have both, and picked ''next'' out of the two so that the computed values would look better, but I was on the fence, as ''auto'' is a better name for the initial value.

Note that once we have a selector for columns in multicol, the computed value of ''next'' / ''auto'' on the columns should probably also be ''next'' / ''auto''.

Here are the options we have:
1 - use ''auto'' rather than ''next'', and keep ''auto'' as the computed value on non-last regions (and columns)
2 - keep ''next'' and not ''auto'' (as per current spec text)
3 - keep both, and have ''auto'' compute to ''next'' on non-last regions (and columns), and to the same value as ''next'' computes to on other things
4 - Rethink the set of values so that they overlap and interact differently

Between 1 and 2, I don't know which one I prefer. I can probably live with either, but neither sound ideal.

I don't really like 3, as having 2 values that do the same thing doesn't sound good.

One possibility for option 4 would be to merge discard and next, call it (for example) break, have it mean "continue in the next region (or column) if there is one, discard otherwise", make it compute to itself in all cases, and have auto compute to it only on non-last regions (and columns). This is what I had initially, but Fantasai really disliked it: "I think discarding anything should be a very explicit behavior.". It also removes the possibility of using the ''discard'' behaviour on non-last regions (and columns), although I am not sure that's really a big loss.

Opinions?

 - Florian

Received on Tuesday, 10 March 2015 21:57:25 UTC