W3C home > Mailing lists > Public > www-style@w3.org > March 2015

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

From: Florian Rivoal <florian@rivoal.net>
Date: Fri, 13 Mar 2015 17:18:03 +0100
Cc: Alan Stearns <stearns@adobe.com>, W3C Style <www-style@w3.org>
Message-Id: <9EC87961-93E3-48F7-B95D-71BC9454E131@rivoal.net>
To: Brad Kemper <brad.kemper@gmail.com>

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

>> 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; }

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 16:18:29 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:30 UTC