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

Håkon Wium Lie wrote:
> Also sprach Del Merritt:
>  > 	:
>  > If the block that is in column style does not specify its height in any 
>  > way, then on paged media the actual height on a given page cannot be 
>  > greater than the page box.
> Correct.
>  > 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:

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.

>  > What I find missing in a paged-media spec are more examples of 
>  > multi-page results.  "Page floats" sort of address this, but I don't 
>  > think the relationship to columns is clear.  This is also why I wonder 
>  > if there is an appropriate way for @page rules to regulate such styling.
> The CSS WG is working on releasing a new version of the multicol
> draft. Hopefully, it will fill in some gaps -- including the
> 'column-fill' property above.
>  > > BTW, You are referring to an old draft of the multi-col spec:
>  > >
>  > >
>  > >   
> ...The reference should have been:
In the newer multicol spec, your section on "Unresolved Issues" - - touches on this 
somewhat.  7.1 references the "overflow" property.  The "overflow" 
property, in turn, is listed in 
as "Media: visual" - which is defined in - 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)

Some clever CSS in an @page rule might allow the first; I don't think 
there is any formal CSS property set that would explicitly allow the 
latter two.

An off-topic question: I have always found the "previous   next   
contents   properties   index" links at the top of CSS21 WDs and such to 
be quite helpful.  Is someone or some group in the CSS3 space attempting 
to maintain a similar list for the CSS3 "modules"?  I particularly like 
the "properties" link; I can see that, with multiple modules, it could 
be an interesting exercise to maintain the list.  At the same time, I 
think the value to the user is high.

Thanks for listening. 


Received on Tuesday, 8 May 2007 17:57:43 UTC