It's the main Wikipedia where it would matter to me. (EN and DE for me).

I assume you know the issue tracker structures/conventions for the main Wikipedia.

Could you please file the issue there on my behalf?

I spent my last free time with this report itself

Now finding out where to report that for the main Wikipedia sure takes me another hour, which I currently don't have. Then sadly this report would just drop unnoticed 🙁

According to T311170: [regression] Communities and extensions should be able to mark up elements so they don't overlap the header https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Features/Sticky_Header#My_templates_use_sticky_elements._How_do_I_get_them_to_work_with_the_sticky_header?, a CSS class should be added to the sticky header of the table to prevent the overlap.

@PutzfetzenORG I'd recommend bringing this up on https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical) and also point to this ticket

Thanks! Directing me to that URL sure saved me 1h of searching/browsing around.
Will report it there.

Done. Reported it. Hoping for a fix. Thanks for your assistance.

If anyone has a proposed local CSS fix, feel free to drop an edit request at https://en.wikipedia.org/wiki/MediaWiki_talk:Gadget-StickyTableHeaders.css

https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#StickyTableHeader_(gadget)_on_English_Wikipedia_hidden_behind_top_header_in_Vector_Skin_2022

There are two problems here..

Problem 1: the JS for the en.wp sticky table headers only runs on tables that are not sortable and the class to compensate therefor has not been applied. I can fix this, BUT

Problem 2: The suggested solution is BROKEN. If you reduce the width of your desktop screen below 1000px, you will note that the sticky header is not enabled. But it seems there isn't a good way to determine the non-visibility of the sticky header. For instance, there is vector-sticky-header-visible on body but this is also applied when due to width the sticky header is NOT visible.. The class mw-sticky-header-element however does not have the same media query offsets.

Am I missing something obvious @Jdlrobson ? Also perhaps we can make the presence of vector-sticky-header-visible conditional on the media width as well using .matchMedia ?

@TheDJ I don't think you need to worry about the visibility of the sticky header. That should be taken care of for you. I'm not seeing any issues with https://de.wikipedia.org/w/index.php?title=Elvis_Presley/Diskografie - note the table of contents icon in the top left below 1000px:

I haven't had a chance to look at your code. Is there a reason you can't use a CSS only solution?

I'm seeing the issues, Your headers are 3.something em down the top of the page, even though there is no header :)

This gadget was also tested a lot by myself and other people at the recent CommTech internal hackathon, see e.g. here. As @TheDJ noted above, the sticky-header class is not added to sortable tables. I did not find a pretty way to fix that because there seems to be no hook that tells you when tablesorter has finished doing its normalizations. So I just went with a hacky solution with setTimeout, see P27790 (it was a hackathon after all).

In T313187#8098254, @Jdlrobson wrote:

I haven't had a chance to look at your code. Is there a reason you can't use a CSS only solution?

That's an interesting question. The thing is, we need to apply position: sticky to the table header, but the header could potentially be very complex, with multiple rows and columns (see tests). If we were to apply position:sticky to every th, they wouldn't stack correctly. Below is an example.

In T313187#8098254, @Jdlrobson wrote:

I'm not seeing any issues with https://de.wikipedia.org/w/index.php?title=Elvis_Presley/Diskografie

First of all, note that this example is on dewiki and it's NOT rendered by the gadget used on English Wikipedia. Instead, the Charttabelle template on dewiki uses templatestyles (rules) to make the headers stick.

Second, your screenshot shows the stacking issue that I was mentioning above -- you can see some empty space below the cells with the country flags. There's actually a header row before the flags that gets hidden once you start scrolling.

This has an easy solution: you just need to put all the headers inside a thead element and apply position:sticky to that. The thing is, you have to rewrite the DOM and need JS for it.

tells you when tablesorter has finished doing its normalizations

We should probably add a new mw.hook regardless if we need it for this specifically or not.

This has an easy solution: you just need to put all the headers inside a thead element and apply position:sticky to that. The thing is, you have to rewrite the DOM and need JS for it.

Yes, ideally we'd move the JS emulateTheadTfoot into the parser, but to do that somewhat efficiently, we'd need parsoid postprocessing filters for that i'm quite sure.

Anyways, I've made a request to solve this for vector-2022 and this particular en.wp gadget with:

@media screen and (min-width: 1000px) {
	.skin-vector-2022.vector-sticky-header-visible .jquery-tablesorter > thead,
	.skin-vector-2022.vector-sticky-header-visible .mw-sticky-header > thead {
		top: 3.125rem;
	}
}

Of note however is that this breaks down if you put the table inside a scroller (which coincidently that page has). Sticky is always relative to the scrollcontext, so if you set 3em as the top offset, the element will always be 3em down from the top of the scrollcontext. Not so much a problem if you skin doesn't have sticky header (like the others) as there the top offset is 0 and that at least is still at the top. I know of no good way to deal with this problem right now, other than making sure that people use a specific classname for the scroller which creates an exception or using more JS to counter that specific problem.

My second point was more that if you have a mw-sticky-header-element, that TOO should probably apply the 1000px media query. And 3rd, ideally the vector-sticky-header-visible should just only be added on the body when the thing is actually visible.

Change 816245 had a related patch set uploaded (by TheDJ; author: TheDJ):

[mediawiki/skins/Vector@master] Only apply sticky header offset if it is showing sticky

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

In T313187#8099270, @TheDJ wrote:

tells you when tablesorter has finished doing its normalizations

We should probably add a new mw.hook regardless if we need it for this specifically or not.

Yeah, definitely. Also:

This has an easy solution: you just need to put all the headers inside a thead element and apply position:sticky to that. The thing is, you have to rewrite the DOM and need JS for it.

Yes, ideally we'd move the JS emulateTheadTfoot into the parser, but to do that somewhat efficiently, we'd need parsoid postprocessing filters for that i'm quite sure.

This is one thing that we explored at the hackathon. We were thinking about adding this to the wikitext parser, maybe as an extension to RemexHTML. It looked quite complex though, and we ended up not doing it. Another stopgap would be to move it to its own RL module, see r790697.

Nice, I already see the Sticky Headers with the Vector Skin in action on the EN Wikipedia.

So much better to consume tables that way! Great work! Thanks!

In T313187#8099241, @TheDJ wrote:

I'm seeing the issues, Your headers are 3.something em down the top of the page, even though there is no header :)

I was referring to the table of contents icon in the top left:

Change 816245 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Only apply sticky header offset if it is showing sticky

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

@TheDJ what's left to do on this ticket? My understanding is this should be fixed now?