- 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>
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. 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 03:59:37 UTC