On desktop with sufficient browser height (determined by a media query on (min-height: $screen-height-place-limit)), make the headers of the BCD table sticky against the bottom of the sticky page header.
Fixes #5417
Problem
On pages with (vertically) long compatibility tables (see, for example, https://developer.mozilla.org/en-US/docs/Web/API/Element), the headers scroll off the top of the screen as the user scrolls down, losing useful context.
Solution
This takes a different approach than #8541 did, by making the table headers sticky in the page scroll context rather than giving the table its own local scroll context. Hopefully that will alleviate some of the issues that cropped up in that other PR.
In my testing this seems to work well. In fact, I was inspired to open this PR when, after reading this Discussion, I noticed / reminded myself that I've been running with the "moral equivalent" of these changes as a local userstyle since last December. So, I've been silently testing these changes without issue for the past 7 months. Of course, that's still a very narrow set of browsers, screen sizes, etc. tested against.
Screenshots
Before
Wide:
Narrower:
After
Wide:
At wider breakpoints, the table is allowed to overlap the page TOC when scrolling past it, which I don't personally feel is a problem. But, it's worth mentioning.
Narrower:
At narrower breakpoints, this causes the entire page to be horizontally scrollable, instead of just the table, which I actually feel is an improvement. (It doesn't make the rest of the page content any wider, so none of it goes offscreen and the only element that needs horizontal scrolling is still the BCD table.)
Also, as can be seen in the Narrower screenshots, this change has a limitation (shared with the left-hand sidebar) in that its top position is fixed at var(--sticky-header-with-actions-height), which == 98px. So, on narrower screens where the sticky header wraps, it will be taller than 98px, causing part of both sticky elements to be cut off at the top.
I feel that limitation could be better addressed by making --sticky-header-with-actions-height a dynamic variable that adjusts itself to account for wrapping. That would solve it for both sticky elements.
How did you test this change?
Created a local userstyle with the same style modifications.
Summary
On desktop with sufficient browser height (determined by a media query on
(min-height: $screen-height-place-limit)), make the headers of the BCD table sticky against the bottom of the sticky page header.Fixes #5417
Problem
On pages with (vertically) long compatibility tables (see, for example, https://developer.mozilla.org/en-US/docs/Web/API/Element), the headers scroll off the top of the screen as the user scrolls down, losing useful context.
Solution
This takes a different approach than #8541 did, by making the table headers sticky in the page scroll context rather than giving the table its own local scroll context. Hopefully that will alleviate some of the issues that cropped up in that other PR.
In my testing this seems to work well. In fact, I was inspired to open this PR when, after reading this Discussion, I noticed / reminded myself that I've been running with the "moral equivalent" of these changes as a local userstyle since last December. So, I've been silently testing these changes without issue for the past 7 months. Of course, that's still a very narrow set of browsers, screen sizes, etc. tested against.
Screenshots
Before
Wide:
Narrower:
After
Wide:
At wider breakpoints, the table is allowed to overlap the page TOC when scrolling past it, which I don't personally feel is a problem. But, it's worth mentioning.
Narrower:
At narrower breakpoints, this causes the entire page to be horizontally scrollable, instead of just the table, which I actually feel is an improvement. (It doesn't make the rest of the page content any wider, so none of it goes offscreen and the only element that needs horizontal scrolling is still the BCD table.)
Also, as can be seen in the Narrower screenshots, this change has a limitation (shared with the left-hand sidebar) in that its
topposition is fixed atvar(--sticky-header-with-actions-height), which ==98px. So, on narrower screens where the sticky header wraps, it will be taller than98px, causing part of both sticky elements to be cut off at the top.I feel that limitation could be better addressed by making
--sticky-header-with-actions-heighta dynamic variable that adjusts itself to account for wrapping. That would solve it for both sticky elements.How did you test this change?
Created a local userstyle with the same style modifications.