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

> On Mar 14, 2015, at 9:51 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
> 
> 
> Brad Kemper
> 
>> On Mar 11, 2015, at 3:18 PM, Florian Rivoal <florian@rivoal.net> wrote:
>> 
>> As noted in the associated issue[1], we need to define how ''continue: discard'' works when the element it is applied to isn't already a fragmentainer.
>> 
>> Rather than defining a new model according to which things may become fragmentainers, I am thinking the I should use the same approach as "continue: fragments" and create a fragment box, the only difference being that you'd only get one, rather than a sequence of fragment boxes.
>> 
>> This implies that ::nth-fragment(1) would work on it, which I think is fine.
>> 
>> Can I go ahead and spec it this way, or does anyone think I should take another approach?
> 
> I like this approach, but I still think that these should all be values of 'overflow' instead of a new property. Then region boxes (those using a valid 'flow-from') get the computed value of 'fragments' (or 'clone' if that's the new name) for overflow if they are not last box. If they are the last box of the region chain then they get the specified value for overflow (which might be authored as 'overflow: discard' and have the behavior you describe above for things that aren't otherwise fragmentainors). 
> 
> Then we don't really need a new 'auto' value, and we no longer need 'region-fragment'. This reduces three properties down to one, and simplifies the conceptual load. 
> 
> We'd have to say how -x and -y overflow works with something overflowing in a logical direction (as 'overflow: fragments | discard | paginate' only applies to the block stacking direction), but IMO we should really do that anyway.

On Mar 18, 2015, at 6:11 AM, Florian Rivoal <florian@rivoal.net> wrote (in a different thread, but it pertains mostly to this):

>> The values are different things, sure, but they don't overlap (a box either overflows or fragments, not both, at least in the block stacking direction). 
> 
> They do overlap. A box can both overflow and fragment in the block direction.
> 
> Look at this example in Firefox or Presto-Opera:
> http://jsbin.com/hubiri/1/edit?output
> 
> When the first column is full, we fragment and continue into the second one. But we also overflow in the block direction, in two ways:
> - the text-shadow overflows in all directions, including block
> - the relatively positioned "ipsum" overflows in the block direction.

I feel myself becoming convinced, even though I don't want to be. :-/

Well. You've explained well. I think what what still needs fixing then, besides finding a better property name than 'continue', is the 'overflow' value. IMO, the description of it implies what I thought, that you switch to paying attention to the 'overflow' property instead of the other 'continue' properties. But now I think it is not so much about "content that doesn't fit overflows", since it can overflow anyway. I think it would be better described as "content doesn't break into fragments, and 'break-*' property values are ignored". Is that accurate for what this would do? If so, I suggest the value be called 'none'. 

For the property name, how about 'breaks', since this is about how to deal with the rest of the content when there is a break? And if you don't think authors would understand 'fragmentation' as a property name, then you probably shouldn't have 'fragments' as a value either. I like 'clone'. It fits well with 'text-decoration-break: clone'. 

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