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

Hey, more about this issue.

Digging into this a little more, the fact the table-cell is anonymous is not the problem here, the problem is linked to this regression in Chrome that has been marked as by design, as far as I understand: https://bugs.chromium.org/p/chromium/issues/detail?id=583670. 

As noted, the behavior for this isn't specified anywhere and still open to interpretation. Chrome Canary current behavior is certainly not going to be what I want to specify though because setting "height:100%" on a cell should *not* have an impact on its sizing, cells do not choose their height, they forcibly inherit the one of their track, independently of their content or of their specified height (though the sizing algorithm will take their specified height into consideration as a minimum if it is a pixel value). 


I think your change is not headed towards a web-compatible solution. Because of a bug in your change, you may not see too much impact for now, but the state you are in is certainly not a great state to be in.

https://jsfiddle.net/bk0qv2dv/ <-- we have a bunch of issues duped to this problem, where websites expect Chrome Stable behavior, and we intended to match you in the spec (and in our implementation when we get to fix it) --- now if you want to match us instead and break those websites, we have no problem with it, but this is not what your latest change did, now you broke it in your own Canary browser worse than it ever was in ours...

https://jsfiddle.net/bk0qv2dv/1/ <-- ... but hopefully for you setting a height (even something stupid like 0px) to the cell make height:100% works properly on the DIV in Chrome Canary (so because of the fix people used for Firefox (when they used one), it should not break on too many sites, even though you don't even care what the author wrote here as long as anything got written; to me this means your current Canary behavior is definitely a bug not a feature, at least from my perspective; Firefox does not apply percentages at all which means your attempt to mimick them is doomed to fail). 

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



> -----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
>

Received on Tuesday, 19 April 2016 18:20:43 UTC