Re: Shrinkwrap, Floats, and Tables

I think we're having a communication problem here. I feel like I'm going
'round in circles.

I wrote, "Currently it is possible to get a shrink-wrap effect with
one-celled tables"

To which you replied, "You should use floats"
and gave the following example:

<div style="float: left; width: 40%">content</div>

This gives me a section of block level content that is 40% wide, and
another section of inline level content that is 60% wide. The widths are
both definitive, not intrinsic.

This would have the same effect as:
<table width="40%" align="left"><tr><td>content</td></tr></table>

Is that what you thought I meant? I never mentioned any attributes.


 | It does actually say that elsewhere (at 17.4):
 | <q>
 | In terms of the visual formatting model, a table may behave like
 | a block-level or replaced inline-level element.
 | </q>
 | But the point is that it behaves as replaced because the effect
 | of the table algorithms is that; in addition, to treat it as
 | non-replaced implies certain things in terms of the way that its
 | margins are calculated.

Ah! The margins! Now *this* is what I speak of.

First of all, the table's treatment. It says above that "a table may
behave like a block-level or replaced inline-level element."

This I interpret to mean (block-level) or (replaced inline-level), not
(replaced block-level) or (replaced inline-level), because I cannot see
how it could be interpreted as something else.

Which is as it should be. A table is not replaced content, and therefore
should be treated as a regular block. _Replaced_ inline is because the
table is treated as a block, and this applies *only* when the table is
inline. Treating the table as inline non-replaced would cause the
content to participate in the containing block's line layout, whereas
the table's content should only participate in an internal layout scheme
and present the entire table as a block frame to the rest of the
document. Therefore, an inline table is treated as inline replaced.

Now for block-level frames and margins. (I will be ignoring borders and
padding as well as 'left' and 'right' for this.)

CSS requires that a block-level element take up its containing block's
entire content width. The equation takes into account the left and right
margins and the content's width.

A replaced element, sans explicit width, presents its intrinsic
dimensions to the layout scheme as width and height. If either or both
margins are set to 'auto', they take up the remaining of the available
space. The calculations are based on the content of the element.

A non-replaced element with an 'auto' width takes its width from the
remaining space after the margins are calculated. All 'auto' margins are
set to 0. The content of the element plays no part in this calculation.

Tables by definition should be non-replaced elements. However, their
width and margins are traditionally calculated according to the
algorithm specified for replaced elements.

All other non-replaced elements have had no traditional rules for
layout. Then CSS imposes its own default on all non-replaced elements
without regard for even the single instance of a precedent, the table.

Then it makes a half-hidden exception for the table, which is, IMO,

~*My Point*~

I see no reason why non-replaced block-level elements can't be treated
the same as replaced block-level elements and have their width taken
from their content, not the containing block. *This* is certainly more
logical than arbitrarily setting 'auto' margins to zero. It is also more
flexible to the page author/designer because they can choose.

Received on Friday, 3 March 2000 23:50:28 UTC