Re: [css3-gcpm] Multi-column floats overflowing the column

Also sprach Del Merritt:

 > >  > When the text, etc., that is in that block 
 > >  > would not fit on a single page, I have missed how it would spill onto 
 > >  > the next page(s), particularly the last page required.  If this was a 
 > >  > 2-column newsletter and there were 10 lines of text that spilled from 
 > >  > Page 1 to Page 2, I think the preferred result would be for all 10 widow 
 > >  > lines to be in column 1, leaving column 2 empty.  Another designer might 
 > >  > think differently.
 > >
 > > Right. We need a property for this. Perhaps:
 > >
 > >   column-fill: auto | balance
 > >
 > > Prince, BTW, supports this:
 > >
 > >    http://www.princexml.com/alpha/2007-04-27/
 > 
 > At first glance, "column-fill: auto;" doesn't seem to have quite enough 
 > of a "knob".  But perhaps, in concert with actively checking 
 > widow/orphan settings, it would do the Right Thing.

Prince also supports widows/orphans, I believe. It would be
interesting if you could try it out and see if you can get it to do
the Right Thing, or if you need more knobs.

 > In the newer multicol spec, your section on "Unresolved Issues" - 
 > http://www.w3.org/TR/css3-multicol/#unresolved - touches on this 
 > somewhat.  7.1 references the "overflow" property.  The "overflow" 
 > property, in turn, is listed in http://www.w3.org/TR/CSS21/visufx.html 
 > as "Media: visual" - which is defined in 
 > http://www.w3.org/TR/CSS21/media.html#visual-media-group - which in turn 
 > leaves me, in "paged" land, wondering just how "overflow" should be 
 > dealt with on a medium sans scroll bars.
 > 
 > Back in the latest-published multicol WD, section 7.1 currently allows 
 > for two options:
 > 
 >     * columns are calculated without regard for the 'height' property.
 >       If the value of 'height' is smaller that the resulting height of
 >       the column boxes, the 'overflow' property is consulted.
 >     * in the calculation of columns, a non-auto 'height' value is
 >       interpreted as a maximum column length. As a result, the number of
 >       columns will be increased.
 > 
 > These are reasonable for "visual" media, but for "paged", the second 
 > will certainly be of no help.  We're confined to the size of the page 
 > box, so if it didn't fit in N columns, it _probably_ won't fit in N+1.  
 > With the first option, in printing applications clipping is the last 
 > thing you *want* to do, though do it you sometimes must.  In the paged 
 > world, other options are possible (and I have seen implemented):
 > 
 >     * scale the data so that it will fit
 >     * flow the data elsewhere
 >     * "posterize" the data, so that it could be manually reassembled
 >       (with tape and glue)

In paged media, wouldn't you just continue on the next page?

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Wednesday, 9 May 2007 13:04:43 UTC