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

Re: [css-overflow] pathological fragment box generation

From: Rik Cabanier <cabanier@gmail.com>
Date: Thu, 4 Apr 2013 21:23:02 -0700
Message-ID: <CAGN7qDCF=ogSb68sVi_0wGRrUCbAmMS8wjVM89TS84ZQQdYTKA@mail.gmail.com>
To: Alan Stearns <stearns@adobe.com>
Cc: "L. David Baron" <dbaron@dbaron.org>, "www-style@w3.org" <www-style@w3.org>
On Thu, Apr 4, 2013 at 8:59 PM, Alan Stearns <stearns@adobe.com> wrote:

> 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
> >>where
> >> 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
> overflow.
>

Does that mean that the fragment container gets a scroll bar?


>
> So the next step is to consider 0-height fragment boxes. Is there anything
> needed for that case if you are choosing to slice?
>
> Thanks,
>
> Alan
>
>
>
Received on Friday, 5 April 2013 04:23:28 UTC

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