Components: Scroll bar should not extend into sticky header for mat-table.

[jrood]

Bug, feature request, or proposal:

When scrolling on a table that has a sticky header, the scroll bar should not extend into the header, but should only come as high as the top of the first row in the table.

What is the expected behavior?

I would expect that, since the table rows are scrolling, the scroll bar would only be as high as the container in which rows are rendered.

What I would expect (for the scroll bar) at scroll position 0:

What is the current behavior?

Currently the scroll bar extends beyond the hight of the first row up to the top of the whole table (including the sticky header).

Current behavior at scroll position 0:

What are the steps to reproduce?

Go to the section in the docs on mat table, scroll down to the section on sticky headers, and then scroll the sample table that has a sticky header.

What is the use-case or motivation for changing an existing behavior?

I think, when this table is used in an app, that the users would expect the scroll bar to pertain only to the part of the table that scrolls, not to the whole table (since not all parts of the whole table scroll in the case of having sticky headers).

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

Angular Material 6.3.0 as it is compiled for the docs.

[aalbericio]

Also note that the scroll bar also extends into the "sticky footer", which, at least for me, is not the expected behaviour.

Would love to see this fixed as soon as possible.

[jrood]

@andrewseguin Perhaps we could use the approach were you duplicate the titles in each <th> with absolute positioned copies.

<th>
  <div style="color:rgba(0,0,0,0)">Col Header</div> // preserves width of the column
  <div style="position:absolute">Col Header</div> // the visible "sticky" header
<th>

[jrood]

The behavior should be like ag-Grid, where the top of the scroll bar matches the top of the scrolling body.

[PRGWITHSTYLE]

Is this still being worked on or simply far in the backlog? I have a bug where I would like to auto-scroll to the top of the table but at the moment unexpectedly scrolls behind the table header. This would completely solve the issue.

[rasmusoe]

I am seeing the same behaviour. It especially causes issues for me when i am trying to use
element.scrollIntoView({ behavior: 'smooth', block: 'start' });
where element is one of the body rows. When clicking the highlighted row the row is placed under the sticky header:

*Edit - Changed images to gif to show both issues.

[thoKling]

Hi guys, any news on this issue ?

[andrewseguin]

The table uses position: sticky for the sticky headers, so it is up to the browser where the scroll bar appears. I also expected the scrollbar to appear only in the content, but it is out of our control. The alternative to this is that we roll our own sticky positioning, but this would incur a heavy performance cost and likely introduce bugs between browsers.

[jrood]

Thanks @andrewseguin . Yes, looking at this W3 spec,

User agents may exploit the head/body/foot division to support scrolling of body sections independently of the head and foot sections

Similarly, if the user agent provides a mechanism to scroll the rows, the header may appear at the top of the scrolled area and the footer at the bottom.

Table rows may be grouped into a table head, table foot, and one or more table body sections, using the THEAD, TFOOT and TBODY elements, respectively. This division enables user agents to support scrolling of table bodies independently of the table head and foot.

It seems, for some reason, most browsers (including Chrome) have chosen not to honor that spec. I would love to be an advocate for getting browsers to do this correctly. @andrewseguin do you know if there's any way we could raise this concern with the Chrome team?

[thoKling]

Hi,
Thanks for your answer.

Why don't you create your own scrollbar component to avoid this ? My idea is to hide the initial scrollbar, and scroll via our own component that could have the size/position we want, and not being attached to the table.

Do you see what I mean ?

[andrewseguin]

Unfortunately I don't have a way to raise this concern with Chrome, the best way is likely for you to just file feedback to them through the chromium channels.