noting that wikidata uses sticky elements as well:

Change 722475 had a related patch set uploaded (by Clare Ming; author: Clare Ming):

[mediawiki/skins/Vector@master] Accommodate other stick elements with sticky header

https://gerrit.wikimedia.org/r/722475

@Jdrewniak Are we sure the scroll padding works with elements that use sticky positioning? I've tried using scroll padding on https://meta.wikimedia.org/wiki/Schema:UniversalLanguageSelector?useskinversion=2&vectorstickyheader=1 and it seems like the sticky elements still overlap the sticky header: https://jumpshare.com/v/4Uq0fo3eiMGlY7TD46wt

Change 722475 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Accommodate other sticky elements with sticky header

https://gerrit.wikimedia.org/r/722475

Status: ✅ PASS
Environment: beta
OS: macOS Big Sur
Browser: Chrome
Device: MBP
Emulated Device: NA

Test Artifact(s):

QA Steps

✅ AC1: Scroll to headers on https://de.wikipedia.beta.wmflabs.org/w/index.php?title=TableTest and ensure that the headers (for the Studioalben table) stick to the bottom of the sticky header.

I have noticed one issue: if I want to jump to one of the references from the footnotes, the position I jump to is below the sticky header, but not below the other sticky elements. Example: try to jump to reference 6 in the Elvis discography; it will be hidden under the sticky table header. Now, this problem is of course already present on these pages even without the sticky site header, but I was wondering if this could be fixed since it can be done for the sticky site header (I guess the unpredictability of the height of such elements makes a solution difficult though).

@XanonymusX can you help me understand the issue you are describing? I clicked the [6] link in the article and was scrolled down to the appropriate reference:

I meant jumping back up! As is visible in your video, the [6] remains hidden under the table header (but not under the site header, that's why I thought that maybe there could be a solution for the overall problem).

Another, presumably more serious issue I just noticed: the sticky site header seems to be not active on diff pages, but other sticky elements on the page will nonetheless be moved down and leave a gap the size of the (invisible) sticky site header! See for example when scrolling down this diff. Either the sticky header is activated for diffs as well, or the other sticky elements must be left as they are on diff pages.

@XanonymusX ah ha, thank you for clarifying. I see the issue.

@Jdlrobson @ovasileva do we have additional work scheduled to address these remaining issues introduced by the sticky header? if not, what are your thoughts on how best to address this stuff?

In T289817#7664327, @alexhollender_WMF wrote:

@XanonymusX ah ha, thank you for clarifying. I see the issue.

@Jdlrobson @ovasileva do we have additional work scheduled to address these remaining issues introduced by the sticky header? if not, what are your thoughts on how best to address this stuff?

Opened T300612: Sticky header: sticky header "gap" appearing on diffs of pages with other sticky elements to track the bug. Let's do some analysis first and then prioritize based on relative difficulty. We are about to do some more small fixes for the sticky header so it's possible we can add this task to that batch

Change 831118 had a related patch set uploaded (by Jdrewniak; author: Jdrewniak):

[mediawiki/skins/Vector@master] Set top value for ToC when sticky header is enabled.

https://gerrit.wikimedia.org/r/831118

👆obove patch unrelated, pasted wrong task number.

I noticed that the matter isn’t fully resolved in all cases. After repeated requests, I have recently modified the header of the chart tables (like the ones in the Elvis example), in order to make both lines of the header sticky. That means that cells in the first row get top:0, while the cells in the second row get top:2.05em. While this works nicely without the sticky header of Vector-2022, the 2.05em are ignored when the sticky header is visible. The 3.125rem would need to be added to the existing top value, rather than replacing it. Not sure if this is easy to fix, but I wanted to report it.

@XanonymusX are you talking about the fact that "Chartplatzierunge" gets hidden on scroll like so?

Ideally instead of applying the top to tbody th we should apply it to thead. Does wikimarkup support the thead element?

Exactly! So far that happened anyway and the row isn’t essential for readers, but with the adjustments I made it remains visible on the other skins, so it would be a shame to have it hidden again with Vector-2022.

@XanonymusX is it possible to rewrite that using thead? If so I think we can do something our end (and I'll open a ticket).

I remember that thead wasn’t generally supported last time I checked, but it’s possible that has changed (was suggested in T42763#7119724 more than a year ago). I can try to rebuild the table (but that will require some testing on Beta)!

Actually, @Jdlrobson, as per T6740#7093395 it is not possible to use thead and tbody in templates because of the Sanitizer. I was also just testing it on beta. So this is not going to help us (unless thead and tbody are finally allowed), unfortunately.

That's annoying. I'm not sure how to do this without thead, so maybe we need to think about addressing T6740 (a 4 digit Phab task!) finally?

You need thead. That’s why I was bashing the browser vendors so much to fix sticky on thead and tr. And why the enwp gadget uses JS to add thead and tfoot.

Since last year all browsers support sticky on thead.

Yes! So how do we get some progress on T6740?