W3C home > Mailing lists > Public > www-style@w3.org > April 2013

Re: [css-overflow] pathological fragment box generation

From: Alan Stearns <stearns@adobe.com>
Date: Thu, 4 Apr 2013 20:59:06 -0700
To: "L. David Baron" <dbaron@dbaron.org>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <CD8398F3.375C3%stearns@adobe.com>
On 4/4/13 8:45 PM, "L. David Baron" <dbaron@dbaron.org> wrote:

>On Thursday 2013-04-04 20:36 -0700, Alan Stearns wrote:
>> There will be some cases where overflow:fragments will generate fragment
>> boxes that can not fit any content fragment, and pathological cases
>> box generation could enter an infinite loop, like this:
>> <style>
>>   .too-big {
>>     height: 100px;
>>   }
>>   .too-small {
>>     height: 50px;
>>     overflow: fragments;
>>   }
>> </style>
>> <div class="too-small">
>>   <div class="too-big"></div>
>> </div>
>Well, the traditional way of handling this sort of case in multicol
>or print is to ensure that every column/page contains *some*
>content, so we never start the next column/page in the same
>situation.  In that model, there's no problem here; the big item
>just gets placed.  (I was assuming that's what css3-break specifies
>or will specify; maybe that's not the case.)

Hmm - I think it does. It mentions slicing monolithic elements as an
option, and if you choose not to slice (say for a video element) then you
have to overflow the fragment container. So you can choose to either make
some progress with a slice or break the constraint on block-direction

So the next step is to consider 0-height fragment boxes. Is there anything
needed for that case if you are choosing to slice?


Received on Friday, 5 April 2013 03:59:37 UTC

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