Tables and the box model

The spec doesn't seem to define how tables interact with the box model.
For example, 
if we have {margin: 0 25%}, the result is a width of 50% from the
non-replaced block model equation, but clearly this doesn't work because
that would serve to increase the width of the table beyond MCW, which
isn't intended at all.

Given that the non-replaced box model can't be used, the following
doesn't seem to be defined:

TABLE {margin-left: 120%}

Now to remove the uncertainty (i.e., because to get this to fit the
containing block, a negative margin is required, but because the box
model equation doesn't work on tables, we can't use it), the status of
margins needs to be defined.

I would propose:
10.3.5 Tables in normal flow

If 'left' or 'right' are 'auto', their computed value is 0. Width is
determined by the browser's table width (or by the fixed layout
algorithm when table-layout: fixed) algorithm. If one of the margins is
'auto', its computed value is given by the constraints above.
Furthermore, if both margins are 'auto', their computed values are
equal. 
(heavily based on:
10.3.4 Block-level, replaced elements in normal flow

If 'left' or 'right' are 'auto', their computed value is 0. If 'width'
is specified as 'auto', its value is the element's intrinsic width. If
one of the margins is 'auto', its computed value is given by the
constraints above. Furthermore, if both margins are 'auto', their
computed values are equal.)

PS. Why aren't there :ltr and :rtl pseudo-classes (:dir(ltr) and
:dir(rtl) seems something of a sledgehammer to crack this particular
nut) - otherwise it is not possible to express the different styles
required for the two directions.

Received on Wednesday, 9 February 2000 09:41:48 UTC