W3C home > Mailing lists > Public > www-style@w3.org > January 2012

Re: min-width and max-width on <table>

From: L. David Baron <dbaron@dbaron.org>
Date: Wed, 11 Jan 2012 14:42:20 -0800
To: Max Vujovic <mvujovic@adobe.com>
Cc: "www-style@w3.org" <www-style@w3.org>
Message-ID: <20120111224220.GA31749@pickering.dbaron.org>
On Friday 2012-01-06 15:44 -0800, Max Vujovic wrote:
> As a web developer, I would expect min-width and max-width to work on the
> table tag like any other tag, as they do in Firefox and Opera. That is,
> they would constrain the table's content width to the range defined by
> min-width and max-width.

Speaking as the person who wrote at least some of the current code
implementing this in Gecko, I wouldn't expect it to work "like any
other tag", although the table itself is less complicated than the
internal table elements (rows, columns, row/column groups, cells)
inside it.

Tables have a layout algorithm for distributing width among columns
that's only defined for widths that are at least the minimum
intrinsic width of the table.  Because of this, max-width shouldn't
be allowed to force the width below the table's intrinsic minimum
width, at least until somebody has a reasonable proposal for how to
extend the width distribution algorithm.

Tables also have much more complicated constraints than other
elements, since all cells in a column have the same (outer) widths,
and the sum of the column widths must sum (with some border spacing
added) to the table width.  This, however, is a problem mostly for
implementing min/max-width on things inside of tables rather than
for tables themselves.  Gecko's support for max-width on things
inside tables is inherently broken; it only sets a maximum on the
effect of the cell on its column, not an actual maximum.  See
http://lists.w3.org/Archives/Public/www-style/2010Jun/0443.html for
a discussion of some of the complexity here.


𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂
Received on Wednesday, 11 January 2012 22:42:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:09 UTC