Table widths in CSS2 and CSS3

A short while ago I posted a message on CSS2 table width calculation. I
didn't get a whole lot of responses, so I thought I'd try again. This
touches CSS3 as well, since at the moment there is no indication that the
table layout algorithms are about to change dramatically. If my little
problem persists, it also points squarely at an addition which would, IMO,
be very healthy for CSS3.

The original problem is as follows: are tables laid out as blocks?

The spec says they are, but goes on to say (in the table section) that
table widths are calculated differently, even when we have
table-layout:fixed. The particular instance I'm dealing with is when we set
table-layout:fixed;width:auto and then determine all box edge properties. In
this case, the table layout part of CSS2 says auto layout is to be applied,
while for block elements this would mean that width is determined by the
edge properties. So, is a table a block or not? This seems an awful lot like
an inconsistency in the spec, since I've found no specific language
addressing the relative priorities of these two definitions.

Now, on my own site I use the interpretation that tables are blocks as well,
and setting the edge properties should determine the width. This is indeed
what IE does, but e.g. Mozilla does auto layout. As the results are
pretty different (see http://www.iki.fi/~decoy/front for reference), this is
a nasty incompatibility, *the source of which should definitely be removed
in CSS3*.

Now, the view that it should be possible to lay out tables according to the
strict box model is in my mind pretty reasonable - on my site, I
occasionally need tables with non-width relative margins that stretch
across the screen (say, 4ex or 2cm margins on left/right, with the rest
filled by the table). If the language in the table width calculation spec
is followed, *this becomes impossible*. Setting width to auto gives us
automatic layout, setting it in percent would give us margins which scale
based on containing block width and setting it absolutely would not scale
at all. The only recourse is to wrap the table in a div, set width:100% and
effect the margins on the div. *But isn't this presentational markup, plain
and simple?*

It seems to me that the line in the CSS2 spec saying table-layout:fixed and
width:auto leads to automatic layout has to be a slip. My intuition leads me
to believe that tables set to fixed layout should be rendered as far as
possible according to the general block model. Only in the case where the
width actually cannot be determined should we use automatic layout. And as
the block width calculation resolves all situations, it is questionable
whether automatic layout should be used at all if it is not specifically
asked for by saying table-layout:auto.

I think this should be clarified or perhaps even changed in CSS2/3. If the
existing table layout spec cannot be changed, I propose that a new value for
table-layout is added which forces the table's box to be rendered strictly
as a non-replaced block with no exceptions for the calculation of width.

It would also be interesting to see whether these width calculation methods
could actually be formulated in terms of replaced and non-replaced block and
inline boxes instead of having their own terminology - the definitions in
the table section suggest that table-layout:fixed gives something like a
non-replaced block, while table-layout:auto signals the replaced kind. After
all, the primary difference between the two kinds of blocks is where the
block size comes from. In the case of non-replaced content, it is more or
less calculated from top (containing block) down. With replaced content, we
go in the opposite direction and use the intrinsic width. It seems like the
two table layout algorithms were meant to produce pretty much these two
situations, one in which the layout proceeds outside-in according to the
block model, and one in which the table has a sort of intrinsic width.

Any comments on the above would be greatly appreciated.

Sampo Syreeni <decoy@iki.fi>, aka decoy, student/math/Helsinki university

Received on Sunday, 17 December 2000 08:05:26 UTC