W3C home > Mailing lists > Public > www-style@w3.org > April 2016

RE: [css-tables-3] Resolving a percentage against a generated table-cell

From: Francois Remy <francois.remy.dev@outlook.com>
Date: Mon, 18 Apr 2016 16:47:37 -0700
Message-ID: <DUB408-EAS99C6457771F60A72BD6D4A56B0@phx.gbl>
To: "'Tab Atkins Jr.'" <jackalmage@gmail.com>, "'Christian Biesinger'" <cbiesinger@google.com>
CC: "'www-style list'" <www-style@w3.org>, "'David Grogan'" <dgrogan@google.com>
It should take its size from the anonymous table-cell. Now, that doesn't mean its size should be 0px. 

Basically, here is what I think should happen (but that Greg and I didn't specify yet, as noted by Tab, because this area is highly not interoperable and we want to do more testing before settling on a behavior, mostly for parts which are not relevant in your test case): 

- 1. To compute the table final height, we have to find out its minimum height:
--------> The only row has height:100% (which is a noop because it will anyway be attributed the whole height of the table, being the only row) and percentages only influence the height distribution so it does not enforce a pixel min-height (a value like height:400px would, because 400px>150px and is therefore taller than the table specified height). 
--------> Another factor is that the table cells must contain its content minimum height. As a result, we compute the minimum height of the table-cell content, which only contains the DIV which has height:100%. In the min-height computation phase, this percentage height results in the height being considered either "auto" if overflow is visible or hidden (like it is the case here), or "0%" if the overflow is scroll (required for compat; edge does not do this and we have tons of site bugs due to this behavior). In this case, it does not matter, the div does not have any content or padding anyway, so its minimum height is 0px.

- 2. Then we have to compute the table final width
As a result of the previous step, the vertical gridmin is 0px. Since the table specified height (150px) is bigger than 0px, this is what will be used as the final table height (we don't have any table-caption, yay!).

- 3. ... and decide how rows will have to divide this height among themselves
The 150px height is being distributed to the rows. This is a crazy thing that I still don't know how we will specify. Hopefully, since there is only one row, it is a sure fact its height becomes 150px (minus any border-spacing) as a result of this step. Cells take the height of their parent row, so the anonymous cell also gets about 150px height.

- 4. Final layout of the the cells content is done at this point
Now, the content of the cell is being layouted for real. At this time, percentages must be resolved against the cell height. As a result, 100% means 150ish pixels, and we get the "expected" rendering. A fun thing is that if you have more than one of those 100% tall DIVs, they will "overflow" the table-cell, which is what happens in Edge/Chrome as far as I know [1].

I therefore believe you should fix the bug. Fixing it goes in the right direction for having Chrome more aligned again with what we want to put in the spec.

Does that makes sense to you?

[1] https://jsfiddle.net/gzapbyeg/2/

> -----Original Message-----
> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> Sent: Monday, April 18, 2016 3:34 PM
> To: Christian Biesinger <cbiesinger@google.com>
> Cc: www-style list <www-style@w3.org>; David Grogan
> <dgrogan@google.com>
> Subject: Re: [css-tables-3] Resolving a percentage against a generated table-
> cell
> On Mon, Apr 18, 2016 at 3:11 PM, Christian Biesinger
> <cbiesinger@google.com> wrote:
> > In this testcase:
> > https://jsfiddle.net/GazzaS/wh1hap33/2/
> >
> > We basically have a display: table-row containing a display: block,
> > leading to an anonymous generated table-cell.
> >
> > How should the percentage in the display: block be resolved? Should it
> > be resolved against the anonymous table-cell, which does not have a
> > height (and therefore be indefinite), or should it be resolved against
> > the display: table-row (and thus be definite)?
> >
> > This was inspired by Chrome's bug report at
> > https://bugs.chromium.org/p/chromium/issues/detail?id=604396
> >From what I can tell, this should be defined by
> <https://drafts.csswg.org/css-tables/#table-layout-algorithm> step 3.6, but
> that currently links to a TODO section, so Fran├žois and Greg need to fill that
> in. ^_^
> ~TJ
Received on Monday, 18 April 2016 23:48:11 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:58 UTC