Proposal: Ember Table 6

[mixonic]

Its that time again! Building on html-next/vertical-collection#400, I propose a new major version of Ember Table.

• Support Ember 3.28+
• Support Node 16+
• Require vertical-collection v5 Proposal: Vertical Collection 5 html-next/vertical-collection#400
• Refactor Ember Components to Glimmer Components https://github.com/Addepar/ember-table/tree/master/addon/components (if apps inherit and extend from these, that may be a challenge and make this not worth doing)
• Change various calculations which rely on browser APIs that were presumed to return accurate values, but actually return rounded integers. This improves scaling calculation stability & accuracy in positioned items. -> Refactor offsetHeight use float-compat API #948
• Remove scss from the demo app / docs site. As at https://github.com/Addepar/ember-table/blob/master/app/styles/ember-table/default.scss. This would remove ember-cli-sass as a dev dep, and address some edge case issues that may occur per Sass issues #973
• Migrate to Volta
• All PRs for 6.0 should target master and use the 6.0 label. See https://github.com/Addepar/ember-table/pulls?q=is%3Apr+sort%3Aupdated-desc+label%3A6.0+

What else?

[gwak]

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)

[apellerano-pw]

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

[apellerano-pw]

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.

[mixonic]

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

[mixonic]

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