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 1/20/15, 1:13 PM, "Florian Rivoal" <florian@rivoal.net> wrote:

>
>== 1 - Generalize 'region-fragment' ==
>
>'region-fragment'
>(http://dev.w3.org/csswg/css-regions/#the-region-fragment-property) 
>currently
>only does anything on the last region of a region chain. But what it does 
>is
>much more generally applicable. On a block container element that has too 
>much
>content to fit, 'region-fragment:break' will cause the element to behave 
>like
>a fragmentainer.
>
>So let's rename ‘region-fragment’ into ‘fragmentation’, move it somewhere 
>else
>(probably the fragmentation spec) as it does not have depend on much of 
>the
>regions spec, and give it a definition along these lines:
>
>Name:       fragmentation
>Value:     auto | break
>Initial:    auto
>Applies to: block containers
>Inherited:  no
>
>On things that are naturally fragmentainers, (pages, columns, non-last 
>regions
>in a region chain...), 'auto' lets them be fragmentainers as they normally
>are.
>
>On things that are not, 'auto' gives the usual behavior: overflowing 
>content is
>processed according to the 'overflow' property.
>
>'break' causes the element to become a fragmentainer. Content that follows
>the break is not rendered (or goes into the next region in the chain if 
>there
>is one). All the things that can be used in a fragmentation context
>(break-before, break-after, widows, orphans, box-decoration-break...) can 
>be
>used.

I think this is an excellent idea, and should replace region-fragment 
entirely. One caveat is that fragmentation:auto should behave exactly the 
same as region-fragment:auto on a region chain. That is, content should 
break in all but the last region, then overflow in the last region. (and I 
just now noticed you got to this in point 9)

>== 2 - Generalize 'max-lines' ==
>Let 'max-lines' (http://dev.w3.org/csswg/css-overflow/#max-lines) apply 
>to any
>fragmentainer. There is no reason to restrict it to any particular kind.

Is there a reason to restrict it to fragmentainers? Why not all block 
elements?

> 
>
>== 3 - Adding the ellipsis ==
>This is the least definitive part of this mail.
>
>One possible approach would be to do something similar to text-overflow. 
>With
>the following syntax: 
>  fragmentation: auto | break [ ellipsis <string> ]?
>
>After layout, remove enough characters and atomic inlines, pushing them
>further in the fragmentation context if any

If you only allow ellipses with break, and break makes the element a 
fragment container, then there is always a fragmentation context (though 
possibly with just one fragment container).

>An alternative would be to do something similar to what the regions spec
>proposes as a processing model for ::after. Having 'fragmentation: break
>block-ellipsis' on a element which is overflowing (and therefore causing
>fragmentation) would insert a ::block-ellipsis pseudo element formatted 
>as a
>block container, whose height reduces the available height in the
>fragmentainer. This is similar to what Tab proposed here:
>http://lists.w3.org/Archives/Public/www-style/2012Jul/0688.html

>This has the advantage of working with any layout system, and
>is well suited for inserting sentences like "Continued on the next 
>page...".
>On the other hand, it does not support just adding "..." at the end of the
>last line.

I think that the main use case for ellipsis is inline, so this should only 
be an explicit alternative or fallback behavior.


>An ::ellipsis (for 'text-overflow:ellipsis' and 'fragmentation:break 
>ellipsis')
>and/or a ::block-ellipsis (for 'fragmentation: break block-ellipsis') 
>pseudo
>should be introduced, with the appropriate property restrictions, to 
>provide
>extra styling to the inserted text.

I agree.

>Also, if we're ever interested in introducing something similar to 
>regions,
>except without naming the flows, we could also have a functional value to 
>the
>'fragmentation' property that takes a selector, and puts the overflowing
>content there.

We have tried this, and there are some annoyances that you’d need to deal 
with. It may be possible to solve these problems, but here’s why we 
abandoned the idea for named flows:

A. One of the simplifications for region chains is that content fragments 
through the chain in document order. Allowing an arbitrary “next” selector 
to identify the next fragment container allows you to fragment into a box 
earlier in the document, which can introduce layout cycles to the fragment 
processing model.

B. Selectors can refer to many boxes. What if the “next” selector selects 
multiple elements? What if the selector for the ‘fragmentation’ property 
selects multiple elements? It’s difficult to restrict the expression to a 
1-1 relationship. And if you allow many-to-one, one-to-many and 
many-to-many there are a lot of edge cases that would need defining away.

<div id=one></div>
<div id=two class=continue></div>
<div id=three class=continue></div>
<div id=oh-no></div>
<div id=help class=continue></div>

#one {fragmentation:break insert-into(.continue) }
#two {fragmentation:break insert-into(#oh-no) }
#three {fragmentation:break insert-into(#help) }
.continue {fragmentation:break insert-into(body) }


>
>== 10 - What about event handling? ==
>Handling clicking and other events in the ellipsis definitely has valid 
>use
>cases, but this is a general css problem of event handling in pseudo 
>elements,
>not something specific to ellipsis. However we solve that will work here.

Agreed, and one of the reasons why we’d need an ::ellipsis

Thanks,

Alan

Received on Tuesday, 20 January 2015 17:43:45 UTC