[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 www-style@w3.org, 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.