The big layout debate v1

Alternative Placing v1
======================

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.

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.

A column's actual width is then determined by the space available in the
parent, but will never be less than the column's minimum width or more
than the column's maximum width.  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.

This is then repeated for rows and height.

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.

This is also then repeated for rows and height.

[1] This is the current align behaviour which I incidently disagree with
but that is a different discussion although it is related.  I've also
left out references to transform since I'm not fully understanding the
intentions of it yet.  (The current spec is ambiguous on the issue.)

=========END=========

I say v1 because I'll no doubt miss something and be required to
renovate it.  However, even this version is far easier to understand
than the current "Placing" section in the reference and also produces
much more intuitive behaviour.

Specifically, the current Placing spec causes mass clipping of boxes to
force them into cells which really doesn't work right.  Instead, I do
away with the concept of cells which are an unneeded addition to the
layout model.

One of the justifications for the current Placing spec is that it is
similar to Gridbag.  Well, we're not targetting gridbag users nor using
gridbag in core code.  Coincidentally, I think that Gridbag sucks.  As a
novice programmer I found it impossible to use, and really wouldn't want
Ibex to model it's behaviour 100% after Gridbag.

Before I can give specific examples to show why the current spec is bad,
a few discrepencies need addressing.

Consider the following example, which creates 2 rows with the first
occupied by a black box an the second a red box and a blue box:

<ibex>
  <box cols=2>
    <box fill="black" colspan="2" />
    <box fill="red" width="50" height="50" />
    <box fill="blue" height="100" />
  </box>
</ibex>

Currently the core clips the blue box.  Reading Adam's secton on Placing
again, I actually think this is a bug in the implementation, but he
insisted it was right during H3.  The problem is the introduction of the
concept of cells confuses matters.

The reference says: "Each column's actual width is set to the maximum
minimum width of all the cells in that column."

What happens currently is the minimum minimum width of any boxes in a
column is used (not the other way around) but Adam suggested I was
confusing cells and boxes.  (Well I never define any cells in Ibex apps
so where do their dimensions come from anyway?)

The reference says: "Each column's maximum width is the largest maximum
width of the cells in the column."

Currently the minimum maximum of a box is also used.  Consider the
following example:

<ibex>
  <box cols=2>
    <box fill="black" colspan="2" />
    <box fill="red" width="50" height="50" />
    <box fill="blue" />
  </box>
</ibex>

Here the core currently crops the blue box to the height of the red box.
"But that makes sense!" I hear you say... not if you read the
smallprint.

A box has two values for each dimension, the minimum and the maximum.
They start off at 0 and MAX_LENGTH respectively.  Which means the
previous example is in reality the equivalent of:

<ibex>
  <box cols=2>
    <box MINWIDTH="0" MAXWIDTH="MAX_INT" fill="black" colspan="2" />
    <box fill="red" width="50" height="50" />
    <box MINWIDTH="0" MAXWIDTH="MAX_INT" fill="blue" />
  </box>
</ibex>

So really, even by the definition of the spec, the blue box should be
the decisive box concerning the height of the row.  (This is mandated by
the spec, the implementation is currently different to the spec.)

I also object to the introduction of the term 'cell' which is needed
merely for these simplifications:

"The minimum width of each cell is computed as the minimum width of the
box occupying it divided by the box's colspan."  And, "The maximum width
of each cell is the maxwidth of the box occupying it divided by the
box's colspan."

These are unecessary simplifications that will avoid to confusing layout
behaviour in complex colspan/rowspan combinations.  If, as I mandate,
colspan boxes would only affect column min/max widths if necessary then
that would be a closer match to the behaviour of HTML tables which do
not equally distribute cell width across the columns it spans if said
columns have an overriding width.

Having reread the spec a few times, I find my current version of the
core to be a closer match (aside from the above cell simplification)
than the core.ibex.org version which Adam was adament was behaving
correctly.  The current implementation causes copious clipping of boxes
to the size of the minimum col/row sibling which isn't not a behaviour
mandated by the current spec.

I conclude that either the either the current implementation is wrong or
the current spec is wrong (ie has mistakes as pointed out above), and
that it is worded very confusingly.
-- 
- Charlie

Charles Goodwin <[email protected]>
Online @ http://www.charlietech.com