[css-tables-3] Recommending to implement fixed header table by css

[workhours]

As CSS Table is reworking, may I say the fixed header table is mostly wanted. The common way to implement a functional fixed header table now is by synchronizing 2 html tables with scripting, it's ugly and complicated. the best way is by giving a height measure to the tbody element if it can works:
#table tbody { height: 20em; }
Above example illustrate a table with a fixed body view of approximate 20 rows regardless how many rows of data it really loaded.

[FremyCompany]

Thanks for the proposal but the current level of the specification tries to document how existing features work in browser, not to add new features.

[SelenIT]

I recall that at some point this approach (fixed height + overflow:auto for tbody) actually worked, maybe in Firefox 1. The possibility to make part of a table scrollable without breaking vertical dependencies of columns (as existing solutions like position:fixed for thead do) seems really useful. Maybe it would make sense to introduce a new value of table-layout (or a new property) that would switch this behavior on?

[SebastianZ]

@FremyCompany Are proposals like this collected somewhere or only kept here?
E.g. https://wiki.csswg.org/ideas offers itself for this.

Sebastian

[FremyCompany]

I didn't close the issue here, just tentatively deferred to next level. I think this is the appropriate way to track proposals with our current GitHub workflow.

[smalllong]

I strongly support this proposal. Fixed, or sticky thead and tfoot are commonly used nowadays. However, it's not easy to achieve these effects by now. Since thead and tbody elements already exists, I think it's not hard for user agents to scroll tbody without affecting thead. I'm tired of using two tables to achieve this effect.

[FremyCompany]

Your assumption is not accurate here because -- at least in Edge but I think also in Chrome -- these elements do not generate boxes. It's literally as if the cells were direct children of the table grid.

[FremyCompany]

I would be curious to see how/if this could be solved for display:subgrid. If we can figure it out in that case, it might be possible to reimplement tables based on grid, and then support more scenarios.

[SelenIT]

@FremyCompany but how does the background for these elements work, if it's not a box?

BTW, it seems that Chrome has recently fixed its very old bug with table rows and table row groups background rendering (probably in issue 122988)?

[FremyCompany]

@SelenIT In our current implementation, the table draws multiple backgrounds in varying positions, to act as if the other elements had a background on their own.

Just checked the fixed Chrome bug. They fixed how the sub backgrounds are being painted, looks like we have the same issue they had, or similar. I don't have the impression they added a box for the thead, they just fixed the code that draws the backgrounds.

[SelenIT]

Chrome has recently fixed a couple of bugs (1, 2) and now it supports relative and sticky positioning for internal table elements like table-row and table-row-group. Does it mean they started to generate real boxes for these display values?

[FremyCompany]

I suspect that it would be the case, but I haven't taken a look yet

[SelenIT]

By the way, as the sticky positioning for any part of the table becomes widely supported, wouldn't this mostly automatically solve this issue (with addition of just one scrollable wrapper)?

[FremyCompany]

I agree. Edge does not support this scenario yet, though.