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

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

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, so I don't have a solid counterproposal model to offer, but I am skeptical about this approach, for reasons similar to what Tab said in this thread:
https://lists.w3.org/Archives/Public/www-style/2015Mar/0308.html

I intend to keep 'page' as a value, at least for now, but given the current lack of a model for pagination, I think it is good to keep exploring possible ways this could work. I've recored your proposal in the spec issues for now. http://dev.w3.org/csswg/css-overflow/#issue-64de292b

 - Florian

Received on Thursday, 19 March 2015 10:18:38 UTC