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: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 13 Mar 2015 14:25:10 -0700
Message-ID: <CAAWBYDDemr323g2VJzL5_VTJJTvcO5EuM4Z2_Z1kxpn4759gvA@mail.gmail.com>
To: Brad Kemper <brad.kemper@gmail.com>
Cc: Florian Rivoal <florian@rivoal.net>, Alan Stearns <stearns@adobe.com>, W3C Style <www-style@w3.org>
On Fri, Mar 13, 2015 at 2:12 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> On Mar 13, 2015, at 9:18 AM, Florian Rivoal <florian@rivoal.net> wrote:
>> 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).

That's not necessarily a problem.

> Does 'continue: scroll' (assuming it comes later with same specificity) reset max-lines to none?

You're mixing up the levels; cascading happens well before computed
values.  The rule would be that "continue: scroll;" (and any other
values that don't trigger fragmentation) will compute to "discard" if
"max-lines" is non-"none".

Received on Friday, 13 March 2015 21:25:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:52 UTC