Robert O'Callahan wrote:
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?
Right.
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?
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.
I see no problem with applying this to floated or positioned blocks.
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?
I guess we could use that as the column height constraint in that case.
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?)
I mean the first implementation. Implementing the width behaviour as in the draft doesn't seem too hard though, we could easily do it later.
[The meta-strategy is to choose a strategy that will 1) get us to something useful working as quickly as possible while 2) being plausibly extensible to full generality over time.]
-- 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).
The real issue is that if a float is allowed to float to the left of its column, and interfere with the previous column, then you trigger a really nasty cycle of dependencies: the placement of the float affects the layout of text before the float in the flow, which affects the placement of the float ...
Thanks for the comments.
Rob _______________________________________________ mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
