Proposal: Ember Table 6 about ember-table HOT 5 OPEN

Hey that's great news! Maybe we could consider

• adding the possibility of providing a custom component for the checkbox instead of relying on css only to style it to correspond to one's design system ?
• floating table header without the need to specify a fixed table height, it's doable in user land but cumbersome (we do it with 2 ember-tables synchronized in a parent component)

from ember-table.

I've cut the first pre-release. v6.0.0-0 is out there, contains the migration to a more accurate scale calculation method.

from ember-table.

The most recent project I built with ember-table had a highly stylized table and we had a lot of issues getting table borders to work with position:sticky table elements.

You can see these visual glitches even on ember-table's own documentation. The header specifies a border style, and it allows content to "peek thru" where the border would be as you scroll. To save you a bunch of SO dumpster diving, this isn't ember-table's fault. It's due to bugs in Chrome's table renderer that are in some cases a decade old, and blocked by undefined behavior in the HTML table spec. Help isn't coming.

One possible solution is to avoid position:sticky altogether in tables. You may have found yourself in this situation before and solved it by creating 2 or more ember-tables and keeping their scroll position in sync somehow. E.g. your header is an ember-table with 1 row. your fixed left column is an ember-table with 1 column. and finally the rest of the content is a third ember-table.

This is a heavy handed workaround, and if it's bothersome enough, perhaps ember-table could implement sticky rows & cols by moving the "many tables, synchronized" into the lib as an implementation detail; saving all the ember-table consumers. And ditch position:sticky and all its foreverbugs

from ember-table.

Thought of another problem with the use of position:sticky. The resize handles can't overlap the line between 2 header cells, which is what users expect.

Expectation: you grab the line to resize

Actual: the handle is on the right edge of the previous cell

You can't set say right: -5px to push it over; it'll be drawn behind the next cell in the header, so you can't interact with the right side of the handle. The only thing that works for modifying draw order of position:sticky elements in tables is to give them cascading z-indexes. Like if you have 10 columns, your first column has z-index 10, your second one has z-index 9, etc. z-index doesn't compose well so it's not a good solution. ember-table already uses z-index for some stuff, and it bleeds into the rest of the application.

from ember-table.

@apellerano-pw I appreciate the analysis and feedback, but I'm not sure any of that work is actionable in the scope of an upcoming major version release. I suspect that analysis might be better in an independent issue.

@gwak I think those changes sound reasonable, but I'm not going to block a major release on them. The sound like reasonable enhancements. I expect the composability of the system is easier to iterate on after we adopt Glimmer components, maybe in the guise of breaking changes for a major version following this one. I'm amenable.

from ember-table.