W3C home > Mailing lists > Public > www-style@w3.org > January 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: Alan Stearns <stearns@adobe.com>
Date: Tue, 20 Jan 2015 23:20:10 +0000
To: Florian Rivoal <florian@rivoal.net>
CC: W3C Style <www-style@w3.org>
Message-ID: <551D299F-C5C7-425D-9B31-F4105519FC44@adobe.com>
On 1/20/15, 10:55 PM, "Florian Rivoal" <florian@rivoal.net> wrote:
>
>>> 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


It’s not impossible to get into that situation with named flows, but we 
try to minimize the ease by which you can find yourself in that situation.

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

So if my markup has multiple paragraphs, and style says:

p { fragmentation:break insert-into(#id) }

Only the first paragraph’s content would fragment and run through the #id 
box? That seems bad to me.

Thanks,

Alan
Received on Tuesday, 20 January 2015 23:20:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:56 UTC