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 Mar 13, 2015, at 9:18 AM, Florian Rivoal <florian@rivoal.net> wrote:
> 
> 
>> On 13 Mar 2015, at 15:24, Brad Kemper <brad.kemper@gmail.com> wrote:
>> 
>> 
>> 
>> 
>>> On Mar 13, 2015, at 2:26 AM, Florian Rivoal <florian@rivoal.net> wrote:
>>> 
>>> 
>>>> On 13 Mar 2015, at 03:16, Brad Kemper <brad.kemper@gmail.com> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Jan 20, 2015, at 2:55 PM, Florian Rivoal <florian@rivoal.net> wrote:
>>>>> 
>>>>> The behavior of max-lines is defined in terms of inserting a fragment
>>>>> break after the specified number of lines. Making it apply on non
>>>>> fragmentainers would have unexpected effects if that definition is kept.
>>>>> "p {max-lines:3;}" would not limit p to 3 lines (To do that, use
>>>>> "p {max-lines:3; fragmentation:break;}"). Instead it would insert a page
>>>>> break after 3 lines into the paragraph if you're on paged media, or do
>>>>> nothing on continuous media, etc, which is probably not what the
>>>>> author intended.
>>>> 
>>>> I think that on continuous media it should just hide everything after the three lines. It would be like 'overflow: hidden', but clipping the text content where you want, without clipping the background or child elements. That seems like it could be useful sometimes.
>>> 
>>> I am not sure I follow you about child elements,
>> 
>> Ah, well it isn't my main point, but I was just thinking that if there were a bunch of (or even just one) block level children before you found 3 line boxes (and those children didn't have line boxes contributing to the count), then you should break before those children, in order to better match the author's intent. But that's a sort of separate topic, I guess.
> 
> It may be the author's intent in some cases, but I am not sure we can say it always is, and authors can already control that explicitly if they want to.
> 
> Let's say you have a div with a bit of text followed by a canvas, and you want content to be hidden/discarded at the earliest of either 3 lines of text or right before the canvas:
> 
> div {
> continue: discard; /* we can make this line optional, see the next point */
> max-lines: 3;
> }
> div canvas {
> break-before: any;
> }
> 
> If you have 3 (or more) lines before the canvas, the cut point will be after 3 lines. If you have less, the cut point will be right before the canvas.

Yeah, OK, I can see that now. 

>>> but otherwise, that's what it does if you combine it with continue:discard [1]. It turns the element into a fragmentainer, so max-lines can apply.
>> 
>> Understood, but my point is that max-lines should give the same sort of look even without needing something to turn the element into a fragmentainor. It could be nearly as useful as 'overflow: hidden', with a variation on what exactly is hidden. That seems like a better choice than having max-lines do nothing in that context.
> 
> That's tricky, because how max-lines works is defined in terms of fragmentation, which is actually what we want when it is applied to a fragmentainer.
> 
> What we could do to avoid the problem of max-lines doing nothing is to say that if the element to which max-lines is applied is not a fragmentainer, it automatically becomes one, which we would do by making the 'continue' property compute to ''discard''.
> 
> That way, we don't need to define two different behaviors for max-lines, *and* it works on regular elements without having to force the author to think about fragmentainers (which is, surprisingly, something most people would rather not think about).
> 
> With that, the previous example can simply be rewritten as:
> 
> div { max-lines: 3; }
> div canvas { break-before: any; }

That would be fine with me. I expect others to object, though, because the value of one property is depending on another (like how floats change 'display' to block). Does 'continue: scroll' (assuming it comes later with same specificity) reset max-lines to none?

> 
> I'll give it a few days, but unless anyone disagrees, I'll update the spec so that it works this way.
> 
> - Florian
> 
>

Received on Friday, 13 March 2015 21:13:09 UTC