Re: The big layout debate v1

Nice work, Charlie!  I largely agree that your proposal is much better
than what we're doing now.  I just need to figure out if it's going to
be computationally prohibitive, but I suspect not.

> Each column's minimum width is set to the maximum minwidth of all the
> boxes in that column.
> Each column's maximum width is set to the maximum maxwidth of all the
> boxes in that column, but no smaller than the column's minimum width.

I assume that if the resulting minwidth is bigger than the maxwidth,
then you increase the maxwidth to be equal to the minwidth?

> A box with colspan occupying several columns will never affect the
> minimum or maximum width of a column any more than is necessary to
> render the box according to it's minwidth and maxwidth properties.

Hrm, this is a really interesting idea.  But it's still not specific
enough... in particular, let's say we have three columns each with
minwidth=20 (as a result of other boxes).  Then there's a box spanning
all of them which has minwidth=70.  Do we split the "extra 10 pixels"
evenly across the columns?

> If possible, the sum of the columns' widths will be equal to the
> parent width.  The instances where this might not be possible are if
> the sum of the columns' maxwidths is less than the parent width or
> if the sum of the columns' minwidths is greater than the parent
> width.

If this is not possible, I assume you align the columns according to
the parent's align attribute?  BTW, this is why I introduced the
concept of "cells"; it's merely there to make describing this
phenomenon easier.


> Packed boxes: Each packed box's actual width is then set to the
> aggregation of the actual width of the columns it spans.  If this width
> exceeds the box's maxwidth, then box is sized to it's maxwidth and
> aligned horizontally according to it's parent's align attribute [1]
> within the space occupied by it's spanned columns.
> [1] This is the current align behaviour which I incidently disagree with
> but that is a different discussion although it is related.

I'd like to hear your thoughts on this in a different thread.  I'm not
entirely happy with the parents-align-vs-childs-align confusion that
currently exists.


> I've also left out references to transform since I'm not fully
> understanding the intentions of it yet.

It's okay; your changes don't affect it (or rather, it doesn't affect
your changes).  That was another part of why I introduced the concept
of cells.  But like I said, it doesn't change the behavior; cells are
just a way of describing how things work.  They don't actually exist.


> Specifically, the current Placing spec causes mass clipping of boxes to
> force them into cells which really doesn't work right.

Er, no, actually the current implementation is just broken ;)


> gridbag in core code.  Coincidentally, I think that Gridbag sucks.  As a

Me too

> insisted it was right during H3.  The problem is the introduction of the
> concept of cells confuses matters.

Oh, okay, now I see what you mean about cells.  Yeah, I agree.

  - a