Re: Fixed table layout and how it affects ancestor widths

On Mon, Jun 14, 2010 at 5:59 AM, Morten Stenshorne <mstensho@opera.com> wrote:
> In recent builds [1] of Opera we have implemented letting tables with
> table-layout:fixed with non-fixed width (i.e. percentual width) affect
> the with of an ancestor shrink-to-fit container or auto-layout table.
>
> This caused some problems, for instance on http://zh.wikipedia.org/ ,
> which now becomes incredibly wide (6000 pixels or so).
>
> Testcase:
>
>    <!DOCTYPE html>
>    <html>
>      <body>
>        <p>There should be no scrollbar</p>
>        <div style="display:table; width:1px;">
>          <div style="display:table; table-layout:fixed; width:100%;">
>            <div style="overflow:hidden;">
>              <div style="width:4000px; height:20px;"></div>
>            </div>
>          </div>
>        </div>
>      </body>
>    </html>
>
> This has started to fail in Opera, because the width requirement of
> 4000px from the inner div is now propagated to the outer table (since
> the fixed-layout table has no fixed width specified). However, I
> believe this is correct behavior (and that the above testcase is
> invalid), although Opera now disagrees with Safari, Chrome, Firefox
> and IE8 (not in compatibility view mode, though).
>
> The CSS 2.1 spec isn't very detailed regarding shrink-to-fit and
> automatic table layout, but to me it seems that child content like
> this (nice and well-behaved, fixed-sized, statically positioned, no
> negative margins, etc.) overflowing a shrink-to-fit or table ancestor
> horizontally is a FAIL.
>
> One thing that all browsers (including Opera) agree on, is that the
> overflow property should not affect the size of an ancestor
> auto-layout table-cell or shrink-to-fit container. One could argue
> that a container with overflow set to 'auto' or 'scroll' hardly needs
> any width at all, since it provides a scrolling mechanism. No (modern)
> browser seems to do it like that, though (which I find reasonable; how
> wide exactly should we require an auto-width container with scrollbars
> to be, then?). I don't know how relevant this is (hopefully not much
> at all), but it seems that all the websites we have found to fail so
> far combine something wide inside overflow:hidden inside fixed-layout
> table inside automatic-layout table. So I'm mentioning it. Again, CSS
> 2.1 isn't very specific here.
>
> So I would like to find out:
>
> 1. Is Opera right in letting content C inside a fixed-layout table B
> affect a shrink-to-fit container or auto-layout table-cell A ancestor
> of B?

I don't think so.  It produces a reverse constraint that I don't think
is expressed anywhere in CSS.  In your test case, for example, the
fixed table is directly stating that it should be 100% the width of
its parent, not that the parent's width should be such that the fixed
table fills 100% of it.

In this specific case, CSS seems pretty clear about how the layout
should work in 17.5.2.1.  Fixed table layouts never depend on the
contents of the cells, but only on the width of the table, the
columns, and the actual cells of the first row.  In the particular
testcase you provided, the fixed table should be 1px wide (100% of its
parent), with no specified column or cell widths, so the single cell
will take up all of the width of the table and be 1px wide as well.

> 2. Are the browsers right in not letting the overflow property on an
> element affect an ancestor shrink-to-fit container or auto-layout
> table-cell?

I believe so.

~TJ

Received on Monday, 14 June 2010 17:53:00 UTC