Robert O'Callahan wrote:The CSS3 draft says the properties apply to "block-level elements". I can't find a formal definition of this term in CSS, but I think we could easily implement it for the blocks that are the interior of table cells.
See http://www.w3.org/TR/CSS21/visuren.html#q5 for the CSS2.1 definition of "block-level". I would expect CSS3 to have a similar definition. I'm not sure that these properties really apply in a sane way to display:table elements, though....
Ah yes. Actually, I think we could do tables. The inner frame would be a table frame instead of a block frame.
I see no problem with applying this to floated or positioned blocks.
Then we need to solve the intrinsic width issue, since almost all floated/positioned blocks in fact have shrinkwrap width.
That's quite easy. When we need to compute a column width from the element width (e.g., because the number of columns is fixed but the width is auto) then we use the availableWidth for the element if a computed width is not available. If the availableWidth is unconstrained then we make the column widths unconstrained. We reflow the column set as I described earlier; it should still work. Each column will be sized to its desired instrinsic width (which means columns can have different widths, but I think this is OK). The column set's intrinsic width can be computed from the column widths and the gap widths. No extra space redistribution will be performed.
For my own sake I want to summarize the basic options for table layout and column count/width computation according to this proposal:
-- column-width:auto, column-count:auto
No columns
-- column-width:auto, column-count:-moz-unlimited
No columns (column-count treated as auto)
-- column-width:auto, column-count:<integer>
<integer> columns, column widths computed by dividing available/computed width by the column count and accounting for column gaps
-- column-width:<length>, column-count:auto
Column count computed by dividing available/computed width by the column width and accounting for gaps; extra space can be redistributed so that columns fill the available/computed width
-- column-width:<length>, column-count:-moz-unlimited
Column count computed by dividing available/computed width by the column width and accounting for gaps; extra space can be redistributed so that columns fill the available/computed width; we avoid overflowing vertically by creating more columns and overflowing horizontally instead
-- column-width:<length>, column-count:<integer>
Fixed column count and widths, horizontal and vertical overflow as needed
I think all of these will work with intrinsic sizing. You just get columns which need to be intrinsically sized, or an unlimited number of columns.
In all these cases, even -moz-unlimited, column height balancing might be needed to be performed. I think we really need to be able to control that with a property. Say column-height-balancing:[balance|none] with 'none' being the default. For elements with a computed or available height constraint, column-height-balancing:none means that you always fill one column vertically before moving to the next. For elements without a height constraint, column-height-balancing:none puts everything in the first column.
Rob _______________________________________________ mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
