Question - Table overflow (scrollbars)

[jmanke]

Check existing issues

• I have checked for existing issues to avoid duplicates

Description

Currently, I'm having difficulty achieving desired horizontal scrollbar behavior with the calcite-table. In my use case, the user should be able to scroll vertically and horizontally, regardless of where in the table they are. In this example, there is a wrapping div with overflow: auto to allow the user to navigate the table. However, there is an overflow-x: auto within the .table-container inside the shadow root. This is causing a scrollbar to appear at the bottom of the rows, so the user must scroll to the bottom before scrolling left/right - not only that, but now there are two scrollbars. Removing the wrapping div's overflow: x doesn't work either since the user would need to scroll to the bottom of the table before scrolling horizontally. The provided codepen goes into more detail.

Example: codepen

Current double x-scrollbar behavior	Desired behavior

Question

Is the desired behavior compatible with A11Y, or should I go about this another way? Is this something that will be addressed in #6646?

Acceptance Criteria

Allow user to scroll the calcite-table vertically and horizontally at any point while navigating the table. In my use case, I'm using an outer div to control the overflow. Either thecalcite-table shouldn't implement internal scrollbars (or expose the ability to override it), or the calcite-table should allow the user to scroll vertically/horizontally as seen in the "Desired behavior" screenshot in the description.

Relevant Info

No response

Which Component

calcite-table

Example Use Case

Ability for user to navigate the calcite-table with scrollbars regardless of their current position in the table.

Priority impact

p4 - not time sensitive

Calcite package

• @esri/calcite-components
• @esri/calcite-components-react

Esri team

ArcGIS Dashboards

[driskull]

@macandcheese seems like the table shouldn't have any scrolling built into it.

[macandcheese]

Scrolling horizontally is something we built in to give some kind of usable experience OOTB at smaller viewports. This is otherwise something end users have to build around this themselves.

It is set inside the component because we display our own UI around the table that needs to remain in place as the table contents scroll - the selection area and slotted actions, and the pagination area:

Screen.Recording.2023-09-05.at.2.02.45.PM.mov

An option could be to expose this value as a public css var (either direct value assignment or an opt-in/out), and let folks opt out of that. I think that would work here.

We could also remove the scrolling altogether when neither of those areas is displayed.

Is the desired behavior compatible with A11Y, or should I go about this another way?

I imagine so but cc @geospatialem to confirm

[driskull]

I would expect more of a layout component to handle scrolling or let the user handle their own scrollable container.

[macandcheese]

We can offer an opt-out via css variable or other means, but we won't be able to contain the UI around the table like in the above video without the rule.

IMO, we also shouldn't just let the component overflow a container, we should have some guardrails built into the component to prevent that - there are plenty of other components where we sticky content and handle scrolling around it, Panel, Modal, List, etc.

[driskull]

List doesn't have any scrolling built in from my understanding.

Panel and Modal are both container layout components that accept other components slotted within them. Table only expects table items slotted inside of it. I wouldn't consider table a layout component.

To me, its kind of weird we have scrolling built into a component that doesn't accept anything slotted content inside of it. I would expect to be able to slot a table component into a panel or shell-panel and have scrolling happen there and not have to deal with double scrollbars.

Now that may be different from the advanced table component which may necessarily need scrolling built in depending on its needs and requirements. However, I would expect this component to behave more like a native HTML table and not scroll by default.

[macandcheese]

I was referring to the filter stickying within list, because it is similar to us handling scrolling here alongside our internally rendered UI.

Table does accept slotted content, and it does render its own UI alongside the Table element, just not all the time. The selection area and pagination are both rendered inside the component.

Even without that, we would still be providing a component that by default will overflow containers and break layout without a user having to add a container to, most likely, add overflow-x scrolling.

I’m all for exposing those variables via css property or finding another way to make it configurable, we should 100% support that.

[driskull]

Looking at the panel, it will scroll but only if necessary. When placed in a container and spanning full height it won't scroll. So maybe its just an implementation change for the table to not scroll when taking full width or height.

[olga-knyazeva]

We have a similar issue when having a table inside a modal, there are 2 horizontal scrollbars, in case the minimum content of the table is wider than the viewport. Here the codepen - https://codepen.io/Olga-Knyazeva-the-bashful/pen/yLZweJG (to see the issue, make the viewport width less than 1450px).

[github-actions]

Installed and assigned for verification.

[DitwanP]

🍡 Verified here