W3C home > Mailing lists > Public > www-style@w3.org > December 2000

css2 table width calculation

From: Sampo A Syreeni <ssyreeni@cc.helsinki.fi>
Date: Sun, 3 Dec 2000 17:38:06 +0200 (EET)
To: <www-style@w3.org>
Message-ID: <Pine.SOL.4.30.0012031710540.18011-100000@kruuna.Helsinki.FI>
Hi!

Up front, I'm a first time poster in this forum. Please excuse me if I'm not
quite up to speed on etiquette or even facts.

I've been doing css for about two years, now, and I've gradually migrated
my site to pure xhtml+css. The other day, I bumped into an interesting
little problem when coding the css stylesheet for my site. It has to do
with table width calculation in the event of fixed table layout. The
problem is, in the section of the css2 spec on calculating widths of block
level, non-replaced elements (which I believe is what display:table
signals), it is made pretty clear that setting borders, paddings and
margins to zero and leaving width to auto forces the calculated value of
width to 100%. At the same time, the section defining table-layout:fixed
tells that having table-layout:fixed and width:auto forces automatic table
layout to be invoked. What's the deal, here? I was not able to find any
explicit language telling which of the two methods overrides the other.
IE5.5 follows the block width formula while Mozilla table layout people
seem stern supporters of the auto-layout interpretation.

It somehow seems to me that tables are pretty special in css - they are
probably the only construct which both has a sort of intrinsic width
(through the auto layout algo) an, OTOH, are freely reflowable (by setting
the width explicitly, which Mozilla and IE both proficiently implement). It
also seems that the logical place to differentiate between these two layout
algorithms is the table-layout property - auto for flexible bottom-up
sizing and HTML fallback, fixed for rapid, more CSSsy top-down layout. So I
think in my case, the block width formula gives more flexibility - there
already is a way to signal auto layout, but if it is not possible to set
the width implicitly through box edge properties (like it is for normal
blocks), we no longer have a way of getting nicely scalable tables with
absolutely set margins (the only ways of setting the table width for fixed
layout are percentages or absolute values, neither of which can be used to
get a constant 1ex or 1cm margin on both sides of the table when the
content width of the containing box changes).

Bold as this may sound, but could the verbiage on table-layout:fixed and
width:auto implying automatic layout be a slip?

Any input is greatly appreciated - at the moment my site looks abominable
with Mozilla and I'd really like to know whether my (perhaps rather hastily
submitted) bug report was a bad mistake or something worth pressing for.

Sampo Syreeni <decoy@iki.fi>, aka decoy, student/math/Helsinki university
Web point of presence: http://www.iki.fi/~decoy/front
Received on Sunday, 3 December 2000 10:38:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:06 GMT