Re: Publishing the flexible box model

L. David Baron wrote:
> On Monday 2008-06-09 19:23 -0700, Andrew Fedoniouk wrote:
>> That is defined in HTML tables already:
>> (See Proportional specifications there)
> Sorry, but that was written by somebody who doesn't understand how
> HTML table width calculation works.  It's poorly defined enough that
> I removed support for it from Mozilla (which I believe was the only
> browser to support it).  (And the way percentages on tables work is
> really halfway between what's described in the spec as percentage
> and what's described in the spec as proportional, since they are
> relative to the actual size of the table, not the space available
> for it.  And percentages will even flex to other amounts when all
> columns have percentage widths.)

Table layout algorithm, indeed, could be defined better.
But I see no problems with flex units by themselves.
They peacefully coexist with other non-flex units.

I believe that was a strategic mistake when percents in tables
were made to behave as flexes.

> It also only defines behavior for widths, and not for margins or
> heights.

Historically html has a model of endless tape.
Limited in horizontal direction but unlimited in vertical direction.
No limits - no context for flex units computation. It was simply
impossible to define flexes for table heights.

CSS has concept of view height so vertical flexes can be added

> It also doesn't define the effect of those proportional units on
> intrinsic width calculation, what their priority is relative to
> other specifications (since the column's width can be specified on
> the column or on any cell), or how they work when column-spanning
> cells are present.  (And I'm not saying that's an exhaustive list of
> what's missing; it's just what I can think of right now.)

Table layout algorithm is pretty simple in fact if to think in terms
of flexes. Wondered at the beginning why it was so poorly defined.

Andrew Fedoniouk.

Received on Tuesday, 10 June 2008 04:56:21 UTC