- From: Florian Rivoal <florian@rivoal.net>
- Date: Tue, 20 Jan 2015 23:55:04 +0100
- To: Alan Stearns <stearns@adobe.com>
- Cc: W3C Style <www-style@w3.org>
> On 20 Jan 2015, at 18:43, Alan Stearns <stearns@adobe.com> wrote:
Thanks for the feedback. Only responding to the points where I have something to add. Presume agreement on the rest.
> On 1/20/15, 1:13 PM, "Florian Rivoal" <florian@rivoal.net> wrote:
>
>> == 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?
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.
The fact that it is defined in terms of fragmentation is what makes
it so nice. We could say that 'fragmentation: auto' computes to
'break' if 'max-lines' computes to something other than 'none' to
save one line in the above scenario. I am not sure this shortcut
is necessary, but I am not opposed to it either.
>> == 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).
Right. I was a bit sloppy with words here. I meant "pushing them further in
the fragmentation context if there is any subsequent fragmentainer in it".
>> 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.
Yes, that's true that you can get layout cycles with this system by going
back in the DOM. But are you sure you can't get them with named flows as
well? For example with exclusions, I think you can. Let's say you flow into
2 elements. The second one in dom order is absposed above the begining of
the first one, and gets an exclusion applied to it. Same issue, no? Granted,
it is easier to get yourself in this sort of mess with what I suggested,
but if it is not impossible with named flows, we'll need a model to deal
with it anyway, and I thought the following did just that:
http://dev.w3.org/csswg/css-regions/#regions-visual-formatting-details
> 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?
Pick the first one of the selected set in DOM order. If that's yourself,
apply the usual loop-detection safety valve and don't flow (i.e.
'fragmentation'computes to 'none' or maybe 'break').
Received on Tuesday, 20 January 2015 22:55:29 UTC