[css-tables] Calc for table layout

[tomalec]

Are there any plans to specify calc behavior for widths and heights in table layout?
Implementations varies across browsers (http://jsbin.com/juqafi/1/edit?html,css,output)

Given the complexities of width and height calculations on table cells and table elements, math expressions involving percentages for widths and heights on table columns, table column groups, table rows, table row groups, and table cells in both auto and fixed layout tables MAY be treated as if auto had been specified.

I suspect the complexity of the math grows when it comes to mix unit (personally, I feel it's just a set of mathematical equations, to be solved in not more sophisticated way that sizing algorithm for Grid Layout).

However, I would say that expressions like:

• calc(10% + 20%) http://jsbin.com/juqafi/1/edit?html,css,output
• calc(100%/7) https://bugzilla.mozilla.org/show_bug.cgi?id=957915

Should be really easy to compute, resolve, and apply.

[miyconst]

+1

[tabatkins]

The Tables module is now receiving some love, so we'll see!

I agree that there are some "trivial" calc()s that should be possible without making anything complicated, but because of that, they're also avoidable. It's easier to write calc(100% / 7) than 14.28%, but the diff isn't huge either.

[FremyCompany]

I don't think this is reflected in the latest CSS Tables draft, but some investigations on this exact topic were conducted by yours truly.

The sad conclusion is that there is probably no way to allow what you want in a way that would work continuously, as width:0% and width:0px have very different behaviors. Heck, even width:10% can have a different behavior than width:10% if specified on consecutive but otherwise perfectly identical column, tables are a complete mess. CSS Grids resolve width distribution in a way that makes it possible to seamlessly mix units, but CSS Tables don't.

I feel no difficulty in supporting calc expression resolving to only one particular unit, but that might mislead authors in believing that calc is entirely supported.

I do not entirely discard the idea of making calc work, but I suspect this cannot make the cut for our current level of the spec, because we would need to add a few new features which is against the spirit of the spec right now, which would add fluidity to the currently one-or-zero behavior of the width distribution. We have so many challenges on that topic already...

[FremyCompany]

Btw, just so you know, mixing units does not work even for one column. It just happens that since you only leave one column unconstrained, it takes the size remaining after you assign its width to the other columns. You can try changing the value as much as you can, it should not have any effect. If it does in some browser, let me know.

[tomalec]

Thanks for your responses :)

It's easier to write calc(100% / 7) than 14.28%, but the diff isn't huge either.

I feel no difficulty in supporting calc expression resolving to only one particular unit, but that might mislead authors in believing that calc is entirely supported.

Supporting calc for non-percentage values, and not supporting it for % is misleading anyways. Even more, "MAY be treated as if auto had been specified" and making behavior different across browsers gives even more confusion to the developers. Maybe, if it's not going to be supported precisely, changing it to "SHOULD" would make it cleaner and more predictable.

CSS Grids resolve width distribution in a way that makes it possible to seamlessly mix units, but CSS Tables don't

The funny thing is that I discovered this issue as CSS Grid is not supported by browsers yet. So I was trying to mimic its behavior by custom element that uses Shadow DOM content distribution and Table Layout.

What about forcing it by table-layout?

Currently, (in Chrome only) setting table-layout: fixed; makes in this particular case width: calc(10px + 50%) works (http://jsbin.com/juqafi/2/edit?html,css,output). I feel that setting it to fixed could mean "Disregard any automagical space distribution, use values I gave".

Forgive me, if lack of sleep made my fantasies to weird, but...
If cutting current spec and breaking pretty stable state is a problem, but CSS Grid does good job on solving such cases, we could make table-layout: grid. Then without breaking existing behavior of Table Layout we could use Grid-like features to style <table>?

[FremyCompany]

This Chrome bug is being tracked in the spec:

Table-layout:fixed causes different width distribution in Chrome
https://drafts.csswg.org/css-tables-3/#bug-list

I initially saw no reason to change the sizing behavior based on the table-layout mode, because this is not at all what that property is about. The fact Chrome switches to a completely different computation mode breaks a lot of things, but of course allows other things to work that cannot work in normal tables (though I never spotted this calc subtlety, thanks for mentioning it). Author feedback is always important, and given Chrome behavior is likely web-compatible, this thread is something we may consider while deciding how to resolve the previous issue.

That being said, CSS Tables will probably not be fixed before CSS Grids is out, and no one would encourage you to rely on CSS Tables more than on a absolute requirement basis, their layout system is slow and buggy.

I will make sure to mention this thread next time we do a breakout session / f2f topic on CSS Tables, but I would encourage further discussions to happen on [email protected], the official mailing list ;-)

[gregwhitworth]

It was resolved in the CSSWG meeting today to move this to L4 of the Values and Units spec to require resolving a calc() that contains values of the same unit.

[gregwhitworth]

Actually, I leave this open until the change is made to L4 of units and values

[fantasai]

OK, I tightened this up in css-values-4 to only allow fallback to auto if the calc() expression mixes both percentages and lengths. The remaining question is about whether fixed table layout should require handling the mix, and if so if that's just for widths or also heights. (Given what fixed layout means, having it work for widths--or the inline size, rather--is perfectly reasonable.)

[gregwhitworth]

Personally, I would prefer for them to be the same, adding additional confusion that you can mix %s with that of lengths only in layout-mode: fixed. This argument is for consistency reasons only, but I think that's a strong argument given the number of inconsistencies already in table layout.

[xiaochengh]

For interoperability, and to reduce frictions in implementing the other proposed math functions, should we turn the "MAY" into "must"?

This issue has also been discussed in the context of min/max(), and the situation seems worse there:

• https://lists.w3.org/Archives/Public/www-style/2011Oct/0735.html (an old one for Gecko)
• https://groups.google.com/a/chromium.org/d/msg/blink-dev/7FaMtRBfTBU/zMzyRG2zAAAJ (a recent one for Blink)

With calc() alone, the value remains a linear function (to the value the % is evaluated against), which means theoretically there should still exist a "correct" intrinsic table size that allows all cells to be sized correctly. UA may choose to do that according to the current spec.

With other math functions introduced, the function is no longer linear and may not even have an inverse, which means the above is no longer possible. In such cases, UA must fall back. For interop, it would be better to specify what fallback should be taken. Turning "MAY" into "must" seems to be the easiest and most reasonable one to me.

[FremyCompany]

Turning the MAY into a MUST sounds reasonable to me. I don't think anyone want to start investigating this more deeply, especially since as noted multiple times the existence of a solution isn't guaranteed.

There still remains the question of fixed layout where percentages can be resolved to pixels and handled as such without too much trouble for most of the algorithm. I would be open to specify that this case must work, and provide the details of how.

[css-meeting-bot]

The CSS Working Group just discussed Calc for table layout, and agreed to the following:

• RESOLVED: Any math expression of a complex type is treated as auto. Simple typed things continue to work as today.

The full IRC log of that discussion

<emilio> Topic: Calc for table layout
<emilio> Github: https://github.com//issues/94
<emilio> xiaochengh: So the issue is what to do with percentages and calc
<emilio> ... spec says a bunch of stuff may be treated as auto
<fremy> "Given the complexities of width and height calculations on table cells and table elements, math expressions involving percentages for widths and heights on table columns, table column groups, table rows, table row groups, and table cells in both auto and fixed layout tables MAY be treated as if auto had been specified."
<emilio> ... I'm proposing changing the MAY into MUST
<emilio> ... it's pretty complicated if we don't treat it as auto
<fremy> q+
<emilio> ... second reason is that this is creating friction when implementing min() / max()
<emilio> ... calc() is complicated, but min() / max() make it a pretty hardly solvable problem
<emilio> ... so I propose to make this a MUST
<emilio> TabAtkins: this is what dbaron proposed back in the day
<emilio> ... and we punted min and max because of that
<emilio> heycam: implementation status?
<emilio> fremy: all browsers match the spec
<emilio> ... for normal table layout
<emilio> ... the algorithm just doesn't make it possible
<emilio> ... in fixed table layout there's one browser that supports percentages based on the size of the table
<emilio> ... as to the question of whether we should remove the behavior for normal table layout is fine
<emilio> ... for fixed layout it'd be nice to also remove it, but Chrome and Safari
<emilio> ... do respect it so it'd be nice to remove that
<emilio> ... or add to the spec that it is respected in fixed table layout and how, which should be straight-forward
<heycam> emilio: there's also the question of whether we should in presence of min and max ...
<heycam> ... Firefox uesd to treat calc(%) as auto
<heycam> ... we no longer do that
<heycam> ... but it raises the question of how min and max behave with only percentages
<heycam> ... I guess that's fine to resolve?
<heycam> TabAtkins: I don't want to special case min and max on type
<heycam> ... that's awkward
<heycam> ... having min and max work in some case if you have certain shapes of expression inside of it
<heycam> emilio: I think given the way we behave, all browsers treat calc with percentages as a percentage, we should do the same for min and max
<heycam> fremy: that sounds reasonable to me
<heycam> .... if there is a sum of % and px, after you've computed, then you decide not to do anything, follow the MUST
<heycam> ... if you have min(10%, 20%), the computed value will be 10%, so you don't have the problem
<heycam> .... I would be in favour of that wording
<heycam> emilio: what about calc(10% + 0)?
<heycam> ... that's simplifies to 10% in all browsers
<heycam> Rossen: yes we've resolved that previously
<heycam> fremy: so what about fixed mode
<heycam> ... I assume it's probably fine to apply this rule to both?
<heycam> RESOLVED: Any math expression of a complex type is treated as auto. Simple typed things continue to work as today.
<emilio> TabAtkins: https://github.com//issues/3482#issuecomment-451590359
<heycam> zoe: no objections

[xiaochengh]

I've made PR #4389 for the resolution above.

PTAL, and thanks for that!

[fantasai]

Seems like this was fixed, so closing out. Please open a new issue if we missed anything. :)