- From: Florian Rivoal <florian@rivoal.net>
- Date: Tue, 20 Jan 2015 14:13:01 +0100
- To: W3C Style <www-style@w3.org>
Warning: this is a long mail, so go grab some coffee. It should of interest to people who care about the "last line ellipsis" problem, but also about fragmentation (including pagination and multicol), regions, and overflow:fragments / overflow:paged. (If that doesn't get me an audience, I don't know what will :) We have an old resolution to add last line ellipsis as a value to text-overflow (or do something similar), but it doesn't say how it would work. ) 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. (spoiler: later in this mail, I extend/generalize this property further) == 2 - Generalize 'max-lines' == Let 'max-lines' ( 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. However, the previous suggestion can, and both can be offered as alternatives to authors to pick from. == 4 - 'overflow:fragment' and 'overflow:paged' == Both 'overflow:fragment' / 'overflow:paged' and 'fragmentation:break' cause a regular element to become a fragmentainer. The only difference is what happens to the content left over after fragmenting. This suggest that they should be rolled up in a single property, and 'fragmentation' is just right for this job. Moreover, Figure 5 in the region spec gives a good explanation of how 'overflow: visible' or 'overflow: hidden' interact with 'fragmentation:break' interact, while the overflow spec has issues (Issue 13/14) on this topic with no obvious right answer. These issues go way if we move 'fragment' and 'paged' to be values of 'fragmentation' (renaming 'fragment' to 'clone'): fragmentation: auto | [ break | paged | clone ] [ ellipsis <string> ]? Unifying the models also gives us the benefit that the ellipsis mechanism now works in each of them. == 5 - Explaining regular pagination / fragmentation == We could also try to use the above as a primitive to explain regular pagination by having 'auto' compute to 'paged' when applied to a page box. We could also have an explicit value to turn off fragmentation on things that would normally fragment, and use it as the computed value of 'auto' on ordinary elements. fragmentation: auto | none | [ break | paged | clone ] [ ellipsis <string> ]? If some values don't make sense in some situations, we can always make then compute to one that does. For example, 'clone' could computes to 'paged' on page boxes, while on descendants of elements where 'fragmentation' computes to 'paged', 'paged' could compute to 'none'. == 6 - Pseudos Elements == On an element where 'fragmentation' computes to something other than 'none', ::after (and probably ::before) should have the same processing model as it has on regions (i.e. it is always a block container). 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. == 7 - Pseudo classes == Having made the generalization in point 5, fragment styling (), so we should reuse that (if we keep it at all). == Conclusion == I think a generalization of 'region-fragment' into 'fragmentation', together with the other related adjustments suggested, would expose a useful primitive, and help unify and simplify how a number of fragmentation-related features work, and open up some new behavior. On top of that, I think this would be a good basis for building multi-line ellipsis, even though I'll readily admit that this part needs more work. If anybody has made it this far, I'd love to hear what you think. - Florian
Received on Tuesday, 20 January 2015 13:13:27 UTC