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: Mon, 8 Apr 2013 12:55:35 -0700
To: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <CD886D31.28244%stearns@adobe.com>
On 4/8/13 12:45 PM, "fantasai" <fantasai.lists@inkedblade.net> wrote:

>On 04/04/2013 08:51 PM, Robert O'Callahan wrote:
>> On Fri, Apr 5, 2013 at 4:36 PM, Alan Stearns <stearns@adobe.com
>><mailto:stearns@adobe.com>> wrote:
>>     There will be some cases where overflow:fragments will generate
>>     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>
>> In Gecko, when there is empty space between the last line and the end
>>of the block, we allow breaking anywhere within that
>> empty space. So in this example we'd break too-big into two fragments,
>>each 50px high. The CSS Fragmentation draft doesn't
>> currently allow this but I think it should --- thanks for bringing it
>Isn't that covered by the Class 3 breakpoints?
>   http://www.w3.org/TR/css3-break/#possible-breaks

I think it does, in this paragraph:

The UA is not required to fragment the contents
of monolithic elements, and may instead either
slice the element's graphical representation as
necessary to fragment it or treat its box as
unbreakable and overflow the fragmentainer.
In both cases it must treat the element as
having Œbreak-inside: avoidı, i.e. only slice
or overflow at the fragmentainer edge if there
are no possible break points on the fragmentainer.

But in the case of a zero-height container where you have chosen to slice,
you're making no progress if you slice at the fragmentainer edge. I
suppose we could do a bit of both in that case (slice some minimum amount
and have it overflow) but I'd rather not *have* to do that, as in some
cases where you know more room is available later in the fragmentation
context you can get a much better effect by skipping the too-small
fragment containers.


Received on Monday, 8 April 2013 19:56:25 UTC

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