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

On Tue, Apr 19, 2016 at 11:20 AM, Francois Remy <
francois.remy.dev@outlook.com> wrote:

> [snip]
> Would the behavior as described in the previous email be something you are
> willing to return to?
>

Yes. I'm currently working on a revert for the/my change that caused this
madness. Then we'll revisit.


> > -----Original Message-----
> > From: Francois Remy [mailto:francois.remy.dev@outlook.com]
> > Sent: Monday, April 18, 2016 4:48 PM
> > 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>
> > Subject: RE: [css-tables-3] Resolving a percentage against a generated
> table-
> > cell
> >
> > 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?
> > Francois
> >
> > +++++++++++++++++++++++++++++++++++++++++++
> > [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
> >
>
>