Step 2: When one of -moz-column-count or -moz-column-width is not auto, have nsCSSFrameConstructor::ConstructBlock construct a wrapper frame
around the block, call it nsColumnSetFrame, similar to the way nsGfxScrollFrame wraps blocks (or WILL wrap blocks once I've rewritten it :-) ). nsColumnSetFrame will be the primary frame for the content (unless nsGfxScrollFrame is instead). nsColumnSetFrame draws borders, background and padding (if it's the primary frame) but suppresses it for the block. We force the contained block to have a space manager and be a margin root.
So a setup similar to how <td> works, basically?
Only blocks will have the multicolumn thing? So something like a table cell (or a fieldset) couldn't do it? (Nothing wrong with that, btw; just sorting out what we plan to do.) What about floated or positioned frames; can those go multicol?
a) if our computed height is unconstrained, then ignore column properties and reflow the block normally. (Don't try to do column balancing, that's really hard). Otherwise,
What about having a max-height but auto height?
b) compute the width of columns. In the first cut, it will just come from the style struct.
First cut of algorithm, you mean? (as in, there is nothing proposed past that now, but eventually maybe we'll think of something?)
-- having floats float between and across columns would be super-hard. It could only really work if a float is only allowed to float to the right (or in RTL, to the left) of its column.
Hmm.. this may be enough for now (and far preferable to it floating all the way across the block, I would guess).
David may have some thoughts on the auto-width issue, since he's been thinking about it for normal blocks...
-Boris _______________________________________________ mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
