- From: L. David Baron <dbaron@dbaron.org>
- Date: Thu, 4 Apr 2013 20:45:47 -0700
- To: Alan Stearns <stearns@adobe.com>
- Cc: "www-style@w3.org" <www-style@w3.org>
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.) It's not clear to me that suppressing this in the case where something won't fit in the current fragment but might fit in a later fragment is an important enough use case to be worth implementing. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla http://www.mozilla.org/ 𝄂
Received on Friday, 5 April 2013 03:46:15 UTC