Template talk:Sticky header

From WikiProjectMed
Jump to navigation Jump to search

Template improvements

Resolved

I asked some JavaScript questions related to improving this template, but I wouldn't hold my breath on it. It also isn't a good solution for when JavaScript is disabled. The best solution would be MediaWiki moving the header rows for all tables (not just sortable) to the <thead> element without JavaScript, basically doing it when the wikitext is translated into HTML. Also wouldn't wait for that either.

I went through every page that uses this template to see what they made sticky, which there were 500 pages (search).

  • 408 pages have tables with one header row (sortable or non-sortable). 61 of those pages have at least one table using {{sorting row}} or have a manually added sorting row (multiple header rows) that will become one header row when replaced with {{sort under}}.
  • 92 pages have at least one table with multiple header rows, which some pages also have tables with one header row.

For the COVID styles:

  • 48 pages have tables with one header row (search).

For {{Import style|sticky}}:

  • 255 (268-13) pages have tables with one header row (search).
  • 13 pages have at least one table with multiple header rows (search).

From the usage (pages: 711 (408+48+255) first row vs 105 (92+13) multi-row), I think this template would be easier to use and more understandable if the main sticky-header class were changed to make the first header row top-sticky, which would work with sortable and non-sortable tables even when JavaScript is disabled. The old sticky class would be obsolete and its usage replaced (38 pages, search). I didn't see any tables targeting a row that wasn't the first with the sticky class, which the same can be said about the COVID styles.

A second sticky-header-thead class can be added for tables that have multiple header rows, which is where most of the potential confusion can occur:

  • Table must be sortable with JavaScript enabled.
  • Avoid making sorttop rows top-sticky (see phab:T355492).
  • Avoid making subsection header rows top-sticky.

Jroberson108 (talk) 20:41, 20 February 2024 (UTC)[reply]

So class=sticky-header would stay in its current location with the wikitable class, etc.. It would only work on single-header tables. But it would work on both sortable and non-sortable tables without any Mediawiki software changes? If so, then I support it.
The 2nd class would be for multi-row headers. Would it work on both sortable and non-sortable tables?
I am trying to simplify use of the 2nd class. It needs a simple name. An additive one. Something like:
  • class=sticky-header-more - as in more rows.
  • class=sticky-header-rows - rows is plural, which is a memory aid.
Where would the 2nd class be placed? Could it be placed on the same line as the wikitable class? Could it be placed by itself with the wikitable class:
  • {| class="wikitable sticky-header-more"
  • {| class="wikitable sticky-header sticky-header-more"
Or would the 2nd class have to go in front of the 2nd header row?:
  • |- class=sticky-header-more
There are some tables with 3 rows that can't be shrunk to 1 or 2 rows. Will just one use of the 2nd class be sufficient? Or will it have to be used for each additional header row after the 1st? That's fine if it can't be avoided. --Timeshifter (talk) 22:04, 20 February 2024 (UTC)[reply]
Correct, sticky-header would work on single-header tables for both sortable and non-sortable without any changed from MediaWiki.
The second class would only work with sortable since the headers need to be moved to the "thead" element and that's the only way to do it currently. If I could add a template script, then it would be different. Like I mentioned above, if Wikipedia:On-demand gadgets is approved or MediaWiki moves the headers, then it might be possible to also do non-sortable tables for multiple headers.
The second class could be named sticky-header-multi. The two classes would be used separately, but added once in the table start wikitext.
Bare minimum:
  • {| class="sticky-header"
  • {| class="sortable sticky-header-multi"
Jroberson108 (talk) 23:39, 20 February 2024 (UTC)[reply]
That all sounds good to me. Including:
class=sticky-header-multi
--Timeshifter (talk) 04:48, 21 February 2024 (UTC)[reply]
@Timeshifter: I think I'm done with the new styles. They are in the sandbox, which you can view the tests at Template:Sticky header/testcases. Jroberson108 (talk) 06:25, 23 February 2024 (UTC)[reply]
The new styles are better on desktop. More stuff is fixed. I see the sorttop problem has been partially fixed. Still a sorttop problem with multi-row headers. Haven't checked in iphone yet. Wanted to write this down before I forgot the desktop test results I was seeing.
The new styles are worse on iphone SE 2020. The sticky headers are not working at all with the new styles. They worked fairly well with the old styles. I need to lower the number of columns so all the test cases fit on the iphone. --Timeshifter (talk) 11:09, 23 February 2024 (UTC)[reply]
See the note at the top of the testcases pages about mobile. Portrait not being sticky relates to fixing "mobile scroll on wide tables is broken" mentioned at #Can someone please add this to the German Wikipedia?. I purposely made the test tables wide to check if mobile horizontal scroll was working again on portrait. Did you try landscape orientation and zooming out? BTW, you can include {{Sticky header/sandbox}} in your sandbox to test one table if that makes it easier. Jroberson108 (talk) 11:44, 23 February 2024 (UTC)[reply]
Zooming out while in landscape view does not work on the iphone. It collapses the page to a small thumb that fits in a grid of thumb tabs. That was for pinch zoom.
I lowered the number of columns to just fit in landscape view on the iphone. Sticky headers (both classes) aren't working at all on the iphone with the new styles. Have tested in Safari and Firefox. They are both in mobile view on the iphone.
I need to try out stuff in my sandbox.
Mobile horizontal scroll is working on the tables in both Safari and Firefox. In both landscape and portrait view. --Timeshifter (talk) 12:04, 23 February 2024 (UTC)[reply]
Minerva skin's horizontal scroll occurs at width < 720px. My phone is 360 x 800 px, which is why I have sticky at landscape 800px width. You can get your resolution at https://www.whatismyscreenresolution.org/ Jroberson108 (talk) 12:19, 23 February 2024 (UTC)[reply]

375x667px on the iphone SE 2020. So you are seeing sticky headers on your cell phone? --Timeshifter (talk) 13:34, 23 February 2024 (UTC)[reply]

Yes, but only in landscape. Your resolution would explain why you don't see sticky. Just curious, do you have everything larger on your phone the same way you do on your PC? Can it be lowered some to test sticky? Doesn't seem like it can be changed from the viewport listed at https://blisk.io/devices/details/iphone-se-2020 Jroberson108 (talk) 18:35, 23 February 2024 (UTC)[reply]
See: User:Timeshifter/Sandbox243. Even when I lowered the number of columns to 5 for some of the tables I still did not have sticky headers on the iphone. But when I lowered the font size from 100% to 85% in Safari the sticky headers worked in all the tables in that sandbox. Even the ones that extended past the edge of the screen. 85% was the first step down that was offered.
In Firefox I just noticed the zoom setting. Previously I was talking about pinch zooming in and out.
Lowering it down one step (to 90%) made the sticky headers work on all the tables. None of the tables extended past the edge of the screen in landscape view.
I don't know where the zoom settings are on Safari. I will have to look around further later.
I don't understand why the sticky header did not work at first in the 5-column table. It fit in the screen width. So did the 6-column table.
--Timeshifter (talk) 21:18, 23 February 2024 (UTC)[reply]
Doesn't look like the other 20 newer iPhones will have issues in landscape orientation with the default font size except iPhone SE 2022 per the viewport settings at https://blisk.io/devices. 7 older ones shouldn't have issues either, assuming their browsers support sticky. Jroberson108 (talk) 00:00, 24 February 2024 (UTC)[reply]

Right now sticky headers are working on nearly all cell phones on single or multi-row headers. Using only class=sticky-header. And the width of the table does not matter on both mobile phones and desktop PCs. Tables are sticky in portrait and desktop view on mobile. See:

The few tables using class=sorttop rows require class=sticky. It only works on tables with a single row of headers. Class=sticky does not work at all on mobile. It works on desktop PCs.

The new styles require 2 classes depending on the number of rows. But they do not require that tables be sortable. Table width does not matter on desktop PCs, or iphones with large enough viewport. I don't know if viewport size effects Android phones. Single-header-row tables using class=sorttop rows work with class=sticky-header. Multi-header-row tables using class=sorttop and class=sticky-header-multi do not work (sorttop rows become sticky).

I prefer the old styles because only one sticky class is needed in almost all cases. I don't mind adding class=sortable to tables to make them sticky.

And the old styles work on nearly all cell phones. Most page views on Wikipedia are from cell phones.

The number of tables using class=sorttop is not that great, and both sets of styles have problems with it.

There are plenty of cell phones with a viewport less than 720 pixels wide in landscape view:

--Timeshifter (talk) 10:45, 24 February 2024 (UTC)[reply]

As already mentioned, the old styles break wide table horizontal scrolling on mobile < 720px and the table was removed from Help:Table because of this. When the old styles are fixed, sticky won't work on mobile < 720px, same as the new styles. Minerva doing this is not a problem since it was intentionally designed that way. I can just as easily break the same feature on the new styles. The question is, is it worth it on a really small screen width? You will have a sticky experience, but instead of horizontally scrolling wide tables with readable text, you would have to zoom out and fit the table on the whole page with smaller semi to not readable text depending on how wide the table is. If you can't read the text, then the sticky feature is a hindrance that you can't disable. This is the experience I have on Android portrait orientation (360px width).
Also, your list includes phones from 10+ years ago that may not support sticky and would have difficulty getting a phone plan for. Finding out what is most used today is a better metric. The first result I found was https://today.yougov.com/ratings/technology/popularity/phone-models/all. Maybe there is a better analytics page somewhere. Jroberson108 (talk) 17:13, 24 February 2024 (UTC)[reply]

I know others with iphones, and some will use them as long as possible. Iphones are known for getting OS updates longer than Android phones. Even after the OS updates end, they will get security updates for a long time. And even after those end the iphones may still work for awhile. I wouldn't recommend putting banking apps on them though, not even on those getting security updates. True security requires iOS updates too. But the phone can still get cell plans, make calls, and go on the web. The camera, and many of the apps, will still work. See models still getting security updates:

With the current sticky header styles I don't have any problem with wide tables on my desktop PC or my iphone. I don't have to zoom or change the font size. Text is readable. Tables with class=sticky-header work fine no matter the width. I am not seeing the problems you are seeing. Of course, I am not on an Android phone, so I have no idea what you are seeing.

For example, see: List of U.S. states and territories by incarceration and correctional supervision rate. As you scroll down the page the tables get wider. And the number of header rows increases. I can see them all on my iphone in portrait and landscape view. Even when I have to scroll horizontally, the tables are sticky and understandable. I can scroll horizontally, and then vertically in a table. So I can see any part of the table even in portrait view, and the sticky header tells me what column I am looking at. Even in the last table that is very wide, and has 3 full header rows. The sticky header rows don't take up much room in portrait view. Even in landscape view they are not overwhelming. For that very wide last table: On my desktop PC I can narrow the browser window, and the table headers are still sticky even with the horizontal scroll bar.

Help:Table problems were not due to sticky headers. I was just trying to avoid any table wider than portrait view on cell phones. Tables of all kinds still work on help pages even when they were wide, but wide tables are less convenient for learning on a help page. I did not want to force people to have to switch to landscape view. This way people can learn from Help:Table even in portrait view on their cell phones. Plus vertical scrolling is smoother when there are no wide tables in portrait view. --Timeshifter (talk) 19:51, 24 February 2024 (UTC)[reply]

Phone updates won't change the viewport size. List of U.S. states and territories by incarceration and correctional supervision rate#Male and female incarceration and correctional supervision is a good example of a wide table and what I'm experiencing. Instead of being able to horizontally scroll that table, it pushes the entire page width beyond Minerva's design, requiring the page to instead be horizontally scrolled. In portrait, I have to zoom out to make sticky work for that table, making the text unreadable both in the table and on the rest of the page. I didn't have to zoom out on the other sections if only those sections are open. If all sections are open, I have to zoom all the way out to make sticky work for any of the tables, again making the page unreadable. Is it the same for you for that table?
"Help:Table problems were not due to sticky headers. I was just trying to avoid any table wider than portrait view on cell phones." That's the exact problem I am experiencing, describing, and the same reason I gave in the other discussion about the help page. Wide tables using the old sticky styles push the page width on Android portrait.
If you are OK with this feature causing accessibility issues (not readable) on at least Android phones, then I can make sticky work. Another option might be to make it work down to 667px width, so at least it works in landscape on your iPhone, not portrait. Jroberson108 (talk) 20:32, 24 February 2024 (UTC)[reply]

Is this helpful?:

Are you able to view the widest table in Android landscape view, and see sticky headers? Are you able to drag the table into view without zooming or changing the font size?

It sounds like we are seeing the same thing in landscape view. On the iphone the table extends past the screen. It makes the whole page wider. But I can drag the table into view. And I see sticky headers.

But in the iphone the same thing happens in portrait view too. I don't have to zoom or change font size or anything. I just drag the table into view a little bit at a time. I have to drag more since so much of the table is offscreen. The sticky header makes it comprehensible.

When I say a wide table makes the page wider I mean I see blank space above the table. Text above and below the table still wraps within the viewport, and doesn't extend beyond the screen. --Timeshifter (talk) 21:23, 24 February 2024 (UTC)[reply]

That link talks about something that needs to be added to the "head" element of the page, not something that templates can do. Also, Minerva already sets a similar viewport.
In landscape view, I have to zoom out to see the entire table before sticky works, which is still readable and does push the page width, but not to the extreme that portrait does. Text outside the table maintains the same page wrap as before, it's just the table that extends beyond the page. Any amount of horizontal scrolling without zooming out to see the entire table means sticky doesn't work. It sounds like the biggest difference is that on iPhone sticky works with horizontal scrolling without the need to zoom out, but on Android sticky doesn't work without zooming out and affecting readability. And other brands and/or models are unknown since we can't test them with sticky. Jroberson108 (talk) 23:10, 24 February 2024 (UTC)[reply]
I adjusted the styles so sticky works on your iPhone and not affect my Android portrait. See if it works on your iPhone landscape and portrait. Jroberson108 (talk) 02:44, 25 February 2024 (UTC)[reply]

Are you using Vector 2022? I assume you are. With the latest test CSS, sticky headers are not working at all in both portrait and landscape view on the iphone. Narrow tables did not work either.

I just checked these pages that have both wide and narrow tables using the test CSS:

I just noticed the complications involved:

You might consider buying a cheap used iphone. This may be where I go if mine breaks: https://www.ebay.com/str/mobileworldny I have bought a couple used PCs from a couple different ebay sellers with warranties, large sales volumes, and high ratings. Very happy with them. Iphone 12 Mini (at $225 used) has 5G, and has probably a couple years or more of full iOS updates, and a couple more of security updates. Even the older SE 2020 ($130 used) has optical image stabilization. End of sales pitch. :) - Keep your Android phone for Wikipedia testing. Or vice-versa. WiFi without a cell plan for one of them. Or hotspot tethered. https://www.apple.com/iphone/compare/?modelList=iphone-12-mini,iphone-se-2nd-gen --Timeshifter (talk) 14:32, 25 February 2024 (UTC)[reply]

Changes in CSS

Resolved
No, its for Minerva, which is what the mobile site uses. https://en.m.wikipedia.org/
I removed the height, which may differ. Can you give that a try? If it doesn't, can you give the dimensions from this site? https://whatismyviewport.com/ Jroberson108 (talk) 17:14, 25 February 2024 (UTC)[reply]
Yeah, I need the viewport width x height from that site for portrait and landscape (not screen size). The viewport is slightly less. Jroberson108 (talk) 17:34, 25 February 2024 (UTC)[reply]

It is working now in portrait and landscape view on the iphone SE 2020. It looks the same as the old styles. Doesn't matter how wide the table is.

The only thing that does not work is sorttop lines combined with multi-header rows. Its sticky headers work, but the sorttop lines are sticky too after sorting. I created a wide table for multi-header rows:

Its sticky headers work too. In both portrait and landscape view.

That link above has the same maximum viewport size for my iphone SE 2020 as what I am seeing here:

But it says the actual viewport (not counting stuff on the top and bottom) is:

  • 667 x 300 in landscape view.
  • 375 x 526 in portrait view.

When I scroll up a page those top and bottom lines disappear. When I scroll down the page they return. --Timeshifter (talk) 21:39, 25 February 2024 (UTC)[reply]

Glad to hear it's working. I added the height you provided, so can you recheck one table in landscape and portrait to make sure it's still working?
For multiple headers (sticky-header-multi), the sorttop row becoming sticky after sorting is the same issue that exists on the current styles. It has to be fixed in sortable per phab:T355492. It works correctly if only one header is sticky with the new sticky-header class.
What disappearing top and bottom lines are you referring too? Something inside or outside the table? Or are you talking about your phone's interface like the soft navigation bar? If it's the interface, then I have the same on my phone, which is normal. Jroberson108 (talk) 23:09, 25 February 2024 (UTC)[reply]

After the latest changes in the CSS, sticky headers stopped working completely in Safari. It still works the same in Firefox.

I checked: https://whatismyviewport.com

The viewport numbers are different between browsers. But same for screen size: 375px x 667px.

  • Safari: Portrait is 375 x 538. And landscape is 667 x 314.
  • Firefox: Portrait is 375 x 526. And landscape is 667 x 300.

--Timeshifter (talk) 00:32, 26 February 2024 (UTC)[reply]

Ok, I reverted the last change. At least the width stays the same. Are there any more tests or is it good to go? Jroberson108 (talk) 01:23, 26 February 2024 (UTC)[reply]
I have no idea. I hope it works for other iphones. I see info about media queries, but I haven't studied this stuff.
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_media_queries/Using_media_queries
https://www.google.com/search?q=media+queries
https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layout/Media_queries
https://www.w3schools.com/css/css3_mediaqueries.asp
Is it working in your Android phone in both landscape and portrait?
--Timeshifter (talk) 01:56, 26 February 2024 (UTC)[reply]
Android landscape has sticky, but not portrait, so it works correctly and the text stays readable. Width 667px makes sticky work in landscape for the missing iPhones that support sticky. Width 375px covers portrait for several iPhones. Both don't affect any other brands, for now. They really should include the height to be as specific as possible in case other brands release a phone with that same width so it doesn't cause readability issues. Unfortunately, there is no way to specify Apple, iOS, or iPhone in the media query, and Wikipedia doesn't support "-webkit-device-pixel-ratio" to increase specificity, so there is a lot of testing involved for this feature to work without causing readability issues for others. If there are other iPhones to test, we can add them, even after going live. I think the styles are good to go as is. Jroberson108 (talk) 02:51, 26 February 2024 (UTC)[reply]
Is Android better with the new styles? In what ways?
I really wish we could get some more users with iphones and Androids to tell us how the old and new styles compare on their cell phones. Maybe at WP:VPT.
--Timeshifter (talk) 03:04, 26 February 2024 (UTC)[reply]
Yes it's better. With sticky disabled on Android portrait, a wide table can be horizontally scrolled and the page is not pushed wider than the content area, which is what Minerva was designed to do. With sticky enabled, the page is pushed wider and the entire table has to be viewed on a small screen for sticky to work, which makes the text unreadable. It's a hinderance that can't be disabled with the old styles. Jroberson108 (talk) 03:22, 26 February 2024 (UTC)[reply]
Also, Android and iPhone aren't the only types of phones. Jroberson108 (talk) 03:25, 26 February 2024 (UTC)[reply]

I am still not clear because I don't know when you are talking of old or new styles.

So with the new styles tables of all widths are sticky without problems or extra steps in landscape view on your Android phone? But not on portrait? Are any tables sticky in portrait view without extra steps or problems? Which ones? Only narrow tables that fit? Do those stop working if a too-wide table is there too?

With the old styles are tables of all widths sticky without problems or extra steps in landscape view on your Android phone? What is going on with portrait view? Same questions.

I am trying to see if there are any substantive improvements on Android with the new styles. --Timeshifter (talk) 03:57, 26 February 2024 (UTC)[reply]

First, I've already said there is an improvement with the new styles on Android, so trust me as I am trusting your iPhone experience. I've given the same reasons several times already. Second, mobile is only one improvement, so I wouldn't get too hung up on this one thing, especially since the styles aren't set in stone. We've both tested it.
The new styles work for me the way they should in desktop (multiple browsers and skins), Android (multiple browsers and orientations), Wikipedia Android app, and when JavaScript is disabled, where everything is readable (no accessibility issues introduced). Do the new styles work for you too? If so, let's go live. Jroberson108 (talk) 04:58, 26 February 2024 (UTC)[reply]
I started a thread at Wikipedia:Village pump (technical). Title may be fine tuned, so search for "sticky header". --Timeshifter (talk) 13:33, 26 February 2024 (UTC)[reply]
Archived here: Wikipedia:Village pump (technical)/Archive 211#Sticky header template for tables. Need iphone and Android testers. --Timeshifter (talk) 03:18, 25 March 2024 (UTC)[reply]

Headings cover the row when you link an anchor in a table

In Vector legacy, if you link to an anchor in a table row then the sticky headers cover the linked row, e.g. in https://en.wikipedia.org/w/index.php?title=List_of_national_capitals&oldid=1215305078&useskin=vector#List. Tested in Firefox, Chrome, Edge. Can this be avoided? PrimeHunter (talk) 09:31, 24 March 2024 (UTC)[reply]

@PrimeHunter: In Vector 2022 in Firefox on Win 10 Pro PC: I get some strange results. In the version you linked to I see what you are seeing.
But when I link directly to the page (which currently is your version):
List of national capitals
the compact TOC letter links go a row or two ABOVE the first instance of that letter.
I haven't checked out Vector legacy (2010) yet. Or other browsers. --Timeshifter (talk) 10:00, 24 March 2024 (UTC)[reply]
@Timeshifter: My link has useskin=vector to display the page in Vector legacy regardless of your preferences. A normal wikilink List of national capitals uses the skin in your preferences. PrimeHunter (talk) 10:08, 24 March 2024 (UTC)[reply]
Oh. OK. I have no idea how to fix the problem. Maybe Jroberson108 can help. --Timeshifter (talk) 12:06, 24 March 2024 (UTC)[reply]
@PrimeHunter: Seems normal for the anchor link to jump to the top of the page, which the sticky headers compete for that space. "Vector 2022" appears to be the only skin not affected for some reason. Did a quick search and found someone using the scroll-margin-top style. I'll give that a try. Jroberson108 (talk) 17:29, 24 March 2024 (UTC)[reply]
Well, that test ended quickly. If I add it to my browser's inspect element, then it works. When adding it to this template, the CSS sanitizer doesn't support it. Warning: Unknown property 'scroll-margin-top'. Looks like there is a way to enable it on MediaWiki, but not for this template. For reference, I tested adding this, where it would later be restricted to certain skins and the 100px fine-tuned.
.sticky-header [id],
.sticky-header-multi [id] {
  scroll-margin-top: 100px;
}
Jroberson108 (talk) 17:53, 24 March 2024 (UTC)[reply]
@Jroberson108: Thanks. Templatestyles have restrictions which are not in user CSS and global CSS. 100px relies on circumstances and is too much for me but 2.2em works fine for me in User:PrimeHunter/vector.css. The code would probably also be permitted in MediaWiki:Vector.css but may be controversial. Some editors want to minimize global CSS. Code in vector.css is apparently also added to Vector-2022 which already avoids the problem and would scroll too much with the code so that should be handled if a global solution is made. I haven't tested other skins. PrimeHunter (talk) 18:21, 24 March 2024 (UTC)[reply]
@PrimeHunter: Yeah, 100px was too much for me too; just an initial test value. It might still move behind the sticky headers if there are multiple or tall headers. Yeah, I can't see them adding it to the global styles, especially for something that is probably on less than 1% of Wikipedia's articles. Glad it works in your user styles. Jroberson108 (talk) 18:41, 24 March 2024 (UTC)[reply]
@PrimeHunter: BTW, I removed ".wikitable" from the styles above if you want to adjust your user styles too. Jroberson108 (talk) 18:48, 24 March 2024 (UTC)[reply]
Thanks. I now use this so it only applies to Vector legacy:
.skin-vector-legacy .sticky-header tr[id],
.skin-vector-legacy .sticky-header-multi tr[id] {
    scroll-margin-top: 2.2em;
}
PrimeHunter (talk) 22:15, 24 March 2024 (UTC)[reply]

@Jroberson108: You wrote that there were around 500 transclusions on Feb 20, 2024 (see your post higher up on that date). Now on March 24, 2024 there are around 900 transclusions. I started the template on Oct 2, 2023. So its rate of adoption by others for tables is speeding up.

Template:Compact TOC. Jroberson108 and PrimeHunter. Could some changes be made to that template to fix this problem somewhat? --Timeshifter (talk) 03:11, 25 March 2024 (UTC)[reply]

@Timeshifter: Looks like there are 23 articles that use both templates out of the 6,802,299 articles on Wikipedia (0.0003%), and that's only if they aren't using the default "Vector 2022" skin, so an even lower percentage.
The issue is that template styles don't support the style that can fix it. {{Compact TOC}} doesn't have a style sheet, so if styles are added to fix it, then it would have to be added to this template. Not sure if there are other styles that can fix it? I haven't looked to see why "Vector 2022" doesn't move the section to the very top of the page.
@PrimeHunter: Looks like some of those 23 articles put the "id" in tr, th, td or span tags, so the "tr" can be removed so it works in more cases. See my adjusted code above. Some add the id manually or through {{anchor}}. List of buses is the only one that uses the sections' id above each table instead of in the tables. Jroberson108 (talk) 04:55, 25 March 2024 (UTC)[reply]
Interesting search method I did not know about:
hastemplate:"sticky header" hastemplate:"Compact TOC"
It probably won't be long before most of the 7000+ transclusions of {{Compact TOC}} use {{sticky-header}}. But since I think one has to be logged in to select Vector 2010, then there may never be a lot of people with the problem.
I hadn't looked at compact TOCs for awhile. I would start using it if it didn't require IDs, or if there were some way to automatically insert them. Also, if it automatically detected which letters of the alphabet were missing in the first letters of the column cells in the first column on the left. Or if some other tool did that. --Timeshifter (talk) 05:54, 25 March 2024 (UTC)[reply]
{{Compact TOC}} may be mostly used with section links like List of poets where there is no table. I made {{Table TOC}} in 2021 for indexing long non-alphabetical tables like The Economist Democracy Index#List by country but it's poorly documented and only has 162 uses so far. PrimeHunter (talk) 09:14, 25 March 2024 (UTC)[reply]
@PrimeHunter:. The table TOC template looks good for tables sorted by major region. Then there is not much TOC stuff to update if the rest of the table has a major update. I count 7 regions in the Democracy Index table. --Timeshifter (talk) 08:16, 26 March 2024 (UTC)[reply]
Yeah, looking at the first page of {{Compact TOC}} transclusions, I see a lot of glossary usage and some table usage. BTW, it and the template you made don't work in Minerva width < 720px (small mobile screens). Works in my Android landscape though. Jroberson108 (talk) 15:19, 25 March 2024 (UTC)[reply]
@PrimeHunter: Looks like it works for "Vector 2022" because scroll-padding-top was added to the global styles, which is another style not supported in template styles. It might be possible for them to add something generic like this to the other global skin styles too, at least the "html" one. It works for "Vector legacy" when I add it to inspect element. Feel free to inquire if you think so too.
@media screen {
  html {
    scroll-padding-top: 75px
  }
}
@media screen and (min-width: 1000px) {
  .client-js.vector-sticky-header-enabled {
    scroll-padding-top:calc(3.125rem + 75px)
  }
}
The second style adjusts the top distance under the sticky header bar (+3.125rem), which doesn't exist on the other skins. Timeless has a sticky header bar at width >= 851px with a height of 3.51em. Finally, Minerva width < 720px {{Compact TOC}} doesn't work, so can exclude it from there. Jroberson108 (talk) 17:35, 25 March 2024 (UTC)[reply]

sticky header template works just about - just makes the data in the lines scroll under it and reappear above the sticky header :)

Note: Thread consolidated to here.

Template for tables with lots of rows (example all 190 countries) and columns (example 12 columns) that leaves the first row visible when scrolling to your country, so you can still understand what data in what column means

Example that shows the issue: https://en.wikipedia.org/wiki/COVID-19_lockdowns#Table_of_pandemic_lockdowns

Hi fellow wikipedians,

I seem to remember there was a sortable table template that could leave the first line indicating what every column data was about and allow you to scroll down and put your country for example just under that line so one could take a screenshot showing what those numbers meant for your country.

Can't find that template anymore.

Thank you, SvenAERTS (talk) 10:39, 28 March 2024 (UTC)[reply]

@SvenAERTS: I added some sticky headers, etc..
Jroberson108 may be able to help further. See also:
Template:Sticky header. Template:mw-datatable. Template:sort-under. Template:Table alignment.
Help:Table/Advanced#Advanced scrolling tables with sticky headers.
The table needs to be broken up into multiple tables. So that the tables are viewable in landscape orientation on cell phones. It is way too wide currently. Even for a desktop monitor.
And rather than being in a template I think it would be better in a separate page. And then linked to the articles rather than transcluded in the articles.
I couldn't figure out how to prevent the first row from being overlapped by the sticky header. I think this is a problem particular to putting a table in a scrolling div. Jroberson108 is an expert in those type of scrolling table divs. --Timeshifter (talk) 12:09, 28 March 2024 (UTC)[reply]

Have a look:

https://en.wikipedia.org/w/index.php?title=COVID-19_lockdowns&wvprov=sticky-header#Table_of_pandemic_lockdowns

when you click edit, you will see that I copy/pasted the "sticky header" (between accolades = { ) at the top of the table. Cheers, SvenAERTS (talk) 13:57, 28 March 2024 (UTC)[reply]

@SvenAERTS:. I consolidated the talk thread here.
I reverted your addition of {{sticky header}} to the article. {{sticky header}} was already in the table template. It adds nothing when duplicated in the article.
See: Template:COVID-19 pandemic lockdowns.
Pinging Jroberson108 from this new consolidated talk thread location.
See article section
COVID-19 lockdowns#Table of pandemic lockdowns.
--Timeshifter (talk) 16:42, 28 March 2024 (UTC)[reply]
@SvenAERTS: Yeah, it's not meant to be put in a scrolling div due to the top of the sticky header being adjusted to be below the top sticky nav bar found in the "Vector (2022)" skin. This is why there is space above the sticky headers and the scrolling data is visible above the headers. I can add a class to apply to the div to remove the spacing and apply some other styles similar to the old COVID sticky styles found at Template:COVID-19 pandemic data/styles.css.
This is the fourth table I've seen where someone put it in a scrolling div. The other ones are South Korea national under-17 football team, South Korea national under-20 football team, and South Korea women's national football team. Jroberson108 (talk) 17:46, 28 March 2024 (UTC)[reply]
@SvenAERTS and Timeshifter: I've updated the sandbox styles. See the new scrollable div class on the testcases page at:
It works in my Windows 10 and Android phone browsers. If it works for you, I can move it live for article usage. If you don't like the div class name "sticky-header-scroll", then we can think up a better name. Jroberson108 (talk) 01:45, 29 March 2024 (UTC)[reply]
Looks good to me on my iphone SE 2020. In both portrait and landscape orientation. Class name is fine. Fast work. Thanks. Do we need to check with a larger iphone too? --Timeshifter (talk) 15:57, 29 March 2024 (UTC)[reply]
There's nothing added that is specific to sizes, so shouldn't be needed. SvenAERTS, do you want to look it over too? Jroberson108 (talk) 18:08, 29 March 2024 (UTC)[reply]
The new class is live now. Jroberson108 (talk) 22:38, 3 April 2024 (UTC)[reply]
@SvenAERTS: Please fix the link in your message here:
https://phabricator.wikimedia.org/T42763#9669355
The smiley face at the end is what is breaking the link. You can edit or delete your messages on Phabricator.
Overall thread:
Phabricator: T42763. Implement repeated/fixed/floating/sticky table headers.
Or delete your message there, since the problem has been solved.
--Timeshifter (talk) 03:37, 10 April 2024 (UTC)[reply]

Accessibility of scrolling tables with sticky headers

@Jroberson108: I found this site:

Might be useful to test a few scrolling tables in sandboxes. Might be useful for many things.

I updated Help:Table/Advanced#Advanced scrolling tables with sticky headers.

It links to a discussion where Graham87 said they were accessible. --Timeshifter (talk) 03:40, 10 April 2024 (UTC)[reply]

On creating a simple template with both row and column sticky headers

Jroberson108 and all interested. In various browsers on my iphone SE 2020 I looked at the scrolling tables with sticky headers linked from these 2 table help sections:

They all work well in all mobile browsers tested: Safari, Firefox, Chrome, Edge, Opera.

I linked to Graham87 comments about there being no problems with accessibility with the 2 methods in those 2 help sections.

As you know the location columns with flags do not sort correctly in cell phones whether the sticky tables are in scroll tables or not. You solved that problem by putting the flags in a separate column in the Covid tables. Later note: Location column with flags does not sort correctly in mobile only for tables using {{sticky header}} alone (not combined with the Covid CSS).

I wonder if a class=sticky-row (or similar simple class name) could be added somehow to {{sticky-header}} such that it would only work if the flags were in a separate column? Or if there were no flags. Or maybe the flags could be in the second column. --Timeshifter (talk) 17:48, 6 July 2024 (UTC)[reply]

@Timeshifter: Why would a "sticky-row" class be needed when there are two classes already to make rows top sticky? How is making a row sticky related to sorting a column? As for Template:2020 monthly cumulative COVID-19 death totals by country, I recall moving the non-critical flags to a separate column not because of sorting issues, but to reduce the width of the critical location column that is left sticky. It was to minimize the amount of space the locations took up when left sticky on small devices like mobile in portrait orientation so that more non-sticky data can be viewed when scrolling.
From the discussion's title, it sounds like you want to make a column left sticky? If so, then you should know that it is only possible if the "sticky-header-scroll" div class wraps the table. If that is there, then something like "sticky-header-col1" and "sticky-header-col2" classes can be created where only one can be added to the table's class attribute. Using both would make them overlap. I've never seen a need for a col3, but col2 is usable in some cases like in the table mentioned above with flag and location columns. It won't work correctly if one of the column's cells spans multiple columns or is spanned by another. Jroberson108 (talk) 19:01, 6 July 2024 (UTC)[reply]
See User:Timeshifter/Sandbox259.
I removed {{sticky header}} from that article table, and used the Covid CSS instead. This fixed the sorting problem in mobile browsers for the location column with flags.
I have been involved with this discussion which uses the Covid CSS:
Wikipedia talk:WikiProject Tennis#1000 title leaders charts
See the wikitext in the table by Qwerty284651:
Wikipedia talk:WikiProject Tennis#Qwerty284651's table
It uses the Covid CSS:
Template:COVID-19 pandemic data/styles.css
Here is the relevant wikitext from the Qwerty284651 table:
<templatestyles src="COVID-19 pandemic data/styles.css"/>
<div class="covid19-container" role="region" tabindex="0">
<div class="scroll-container">
{{mw-datatable}}{{sort under}}{{table alignment}}
{| class="wikitable sortable mw-datatable defaultcenter col1left sort-under-center sticky-col1" style="margin:0; font-size: 90%"
|- class="sticky-row"
I got confused by the meaning of class="sticky-row". Ignore that mistake. I struck it out in my previous comment.
I am wondering if it is possible to create something like Template:Sticky header full (or similar simple name) that somehow adds the divs without the editors having to see it, or deal with it. In other words the relevant wikitext would be a lot shorter:
{{mw-datatable}}{{sort under}}{{table alignment}}{{sticky header full}}
{| class="wikitable sortable mw-datatable defaultcenter col1left sort-under-center sticky-col1" style="margin:0; font-size: 90%"
|- class="sticky-row"
Another benefit, besides simplicity, would be a full documentation page, if the CSS were part of Template:Sticky header full
Would it be possible to substitute class=sticky-header and class=sticky-header-multi for class=sticky-row? And to keep those classes with the line of other classes in the top line of the table wikitext?
That way people could easily convert from {{sticky header}} to {{sticky header full}}. Just by adding "full" and adding sticky-col1 or sticky-col2 to the long line of classes.
Better yet, if all of this could be incorporated into {{sticky header}}. Then the only change people would need to make to get sticky row headers is to add sticky-col1 or sticky-col2 to the long line of classes.
I am wondering why {{sticky header}} is necessary in the full sticky table at the link below, but is not in the above wikitext.
Iga Świątek career statistics#Wins against top 10 players
Its relevant wikitext:
<templatestyles src="COVID-19 pandemic data/styles.css"/>
<div class="covid19-container" role="region" tabindex="0">
<div class="sticky-header-scroll" style="max-height:50vh">
{{mw-datatable}}{{sticky header}}{{sort under}}
{| class="wikitable mw-datatable plainrowheaders sortable sort-under-center sticky-header sticky-col2" style="margin:0"
|-class="sticky-row"
I tried removing {{sticky header}} in preview, but it broke the table.
--Timeshifter (talk) 01:57, 7 July 2024 (UTC)[reply]
@Timeshifter: I do see an issue with sorting on mobile, but it doesn't look like it has anything to do with sticky headers. I tested the below two links in Chrome and Firefox on Windows 10 and the mobile version sorts Palestine at the top even when I remove all the classes except wikitable and sortable in the edit preview.
The issue appears to be {{flagg}} on the mobile version since sorting works on the desktop version. Jroberson108 (talk) 06:38, 7 July 2024 (UTC)[reply]
As far as adding divs through a template, an editor would have to add two templates, one for the opening div before the table and one for the closing div after the table. Something like {{sticky header start}} and {{sticky header end}} could be created. Editors would still need to add the specific classes to the table. It doesn't seem simpler, especially if someone wants to style the opening div with less height like with style="max-height:50vh", which now would require passing it through the template properties. Jroberson108 (talk) 07:36, 7 July 2024 (UTC)[reply]
I need to test some more flag templates with {{sticky header}}.
I forgot to point you to this:
User:Timeshifter/Sandbox259#Partially-sticky table. Not in scroll window
I don't know if you saw it. It also uses the Covid CSS. It seems that removing this line of wikitext also removes the top sticky headers from desktop PC browsers:
<div class="scroll-container">
The sticky row headers still work in both desktop and mobile. But the top sticky headers only work in mobile browsers.
See again: Wikipedia talk:WikiProject Tennis#Timeshifter's table - Uses the Covid CSS.
I summarized my test results: The table there (when nowrap is ignored or removed) is working perfectly on my desktop PC monitor in Windows 10 Pro. Also on my iphone SE 2020 (in portrait and landscape view). It has been tested in Safari, Firefox, Chrome, Edge, and Opera. The row and column headers are both sticky.
Does it work perfectly for you too in an Android phone?
{{sticky header start}} and {{sticky header end}} sound good to me. I want to start using it right away since it works perfectly. style="max-height:50vh" is rarely necessary. I would like all the class names in the first row of table wikitext if possible. But I will take what I can get.
I think the default should be row and column sticky headers. But not within a scroll window. That would require a "scroll" class. So someone could set up a fully-sticky table in a scroll window with just this:
{{sticky header start}}
{| class="wikitable sortable sticky-header scroll"
|- 
...
|}
{{sticky header end}}
It would be very easy to convert from {{sticky header}} to it, and thereby add sticky row headers and a scroll window.
I can't see why sticky row headers shouldn't be default.
Is is possible to make sticky row headers the default in {{sticky header}}? No scroll window. In other words no changes would have to be made on the 2000+ existing transclusions (using classes sticky-header and sticky-header-multi).
{{sticky header}}
{| class="wikitable sortable sticky-header"
|- 
...
|}
--Timeshifter (talk) 11:17, 7 July 2024 (UTC)[reply]

@Timeshifter: I'm not sure why issues with the Template:COVID-19 pandemic data/styles.css template are being discussed here. It's a competing template that has not been thoroughly tested and should not be used in conjunction with this template on the same table. It was made a long time ago for the covid tables and only recently has it been applied to the sports tables. The only reason I can think of that it was used outside of its original scope was because they wanted horizontal scroll and an optional left-sticky column that this template didn't offer. The horizontal scroll is now available with the div wrapper. As indicated above, left-sticky can be added to this template, but like the covid styles, a div wrapper is required for it to work. As I indicated at Template_talk:COVID-19_pandemic_data/styles.css#Why_is_Firefox_table_slightly_cut_off_horizontally?, this template has been thoroughly tested whereas the covid one has not, so the covid one will have issues in other skins, etc.

The original intent of this template was to provide the most common usage, which is for top-sticky row(s). Adding the div wrapper to this template and now wanting left-sticky columns is complicating this template and the documentation, as you are obviously trying to sort out in this discussion.

Options for the new left-sticky feature would look something like this.

OPTION 1:

Add left-sticky to this template, which further complicates documentation.

Row 1 top-sticky, no left-sticky: 

{{sticky header}}
{| class="wikitable sortable sticky-header"
|}

or 

{{sticky header}}
<div class="sticky-header-scroll">
{| class="wikitable sortable sticky-header"
|}
</div>

Row 1 top-sticky, column 2 left-sticky: 

{{sticky header}}
<div class="sticky-header-scroll">
{| class="wikitable sortable sticky-header sticky-header-col2"
|}
</div>

No top-sticky, column 2 left-sticky: 

{{sticky header}}
<div class="sticky-header-scroll">
{| class="wikitable sortable sticky-header-col2"
|}
</div>

OPTION 2:

Create start/end templates, add left-sticky to the start template, move the div wrapper to the start template, include this template in the start template so editors don't have to if they want the optional top-sticky row(s). This template returns to a simpler version and moves the complexities to the start template. This is unadvisable since it greatly complicates the styles, testing, and documentation. Technically start/end aren't good names since left-sticky is a new feature not found in this template. The start/end templates I have examined don't add new features.

Row 1 top-sticky, no left-sticky: 

{{sticky header}}
{| class="wikitable sortable sticky-header"
|}

or 

{{sticky header start}}
{| class="wikitable sortable sticky-header"
|}
{{sticky header end}}

Row 1 top-sticky, column 2 left-sticky: 

{{sticky header start}}
{| class="wikitable sortable sticky-header sticky-header-col2"
|}
{{sticky header end}}

No top-sticky, column 2 left-sticky: 

{{sticky header start}}
{| class="wikitable sortable sticky-header-col2"
|}
{{sticky header end}}

OPTION 3:

Create new start/end templates and add everything there so sticky tables are always wrapped in a div providing horizontal scrolling when the tables are wide. Always having the div would fix the Android issues with wide table scrolling mentioned at Template:Sticky header#Known issues. This template could be deleted once transclusions are replaced since it duplicates some of the start/end features. If this template is kept, then this template's div wrapper can be removed to simplify it and this template will be a separate competing template to the start/end templates, which it might be prudent to have a more descriptive name like maybe "sticky header box start" and "... end", but this template's Android issues will remain. The start/end templates are what I originally planned so the horizontal scroll and left-sticky column features were possible just like the covid styles, but this template was created so I didn't bother.

Row 1 top-sticky, no left-sticky: 

{{sticky header start}}
{| class="wikitable sortable sticky-header"
|}
{{sticky header end}}

Row 1 top-sticky, column 2 left-sticky: 

{{sticky header start}}
{| class="wikitable sortable sticky-header sticky-header-col2"
|}
{{sticky header end}}

No top-sticky, column 2 left-sticky: 

{{sticky header start}}
{| class="wikitable sortable sticky-header-col2"
|}
{{sticky header end}}

Jroberson108 (talk) 15:56, 7 July 2024 (UTC)[reply]

Having seen how wonderfully the Covid CSS works with all browsers on my iphone SE 2020 portrait and landscape views, I want the same for Android phones too. So I guess that means option 3. As long as there is a scroll window option with it.
Can that be done with a class alone? For example: class=scroll.
I always prefer the simplest names: "sticky header start" versus "sticky header box start". And sticky-col2 versus sticky-header-col2.
I no longer care what happens with {{sticky header}}. It will disappear over time, especially if these new start/end templates work as well with Android phones as they will do with iphones. That is if they duplicate the capability of the Covid CSS.
--Timeshifter (talk) 18:53, 7 July 2024 (UTC)[reply]
@Timeshifter: If option 3 and removing {{Sticky header}}, then {{Sticky header start}} and {{Sticky header end}} makes sense.
Wikipedia:TemplateStyles gives guidelines to name the classes based on the template name, so "sticky-header-col1" and "sticky-header-col2" better follow that. "Use selectors that are highly likely to be unique to the template being used. This reduces the chance of conflicting CSS rules arising accidentally. Examples: Use .myTemplate-row rather than .row or .myTemplate tr rather than tr."
There wouldn't be a need for editors to add a scroll class. Transcluding the start template would add the template's styles and the opening div tag with its class. An optional parameter would be added to the start template so editors can add/override the div styling like with "max-height:50vh". Example property use: {{Sticky header start|style=max-height:50vh}}. Jroberson108 (talk) 21:13, 7 July 2024 (UTC)[reply]
So the scroll window would be the default? If so, then there would be a need for a class=noscroll in some cases. Not all sticky tables need to be in a scroll window. I guess small tables would automatically not have a scroll window since they wouldn't extend past the screen. And some tables slightly taller than the screen may not really need a scroll window, and so some article editors may not want them in a scroll window.
I think the spirit of the Wikipedia:TemplateStyles guidelines is met by "sticky-col1" and "sticky-col2". Or col1sticky and col2sticky. I don't know of any other sticky templates, etc. that use those class names. Kind of like col1left and col2right are adequately distinct for {{table alignment}}.
{{Sticky header start|style=max-height:50vh}} is fine. I don't think it will be used very often.
--Timeshifter (talk) 22:48, 7 July 2024 (UTC)[reply]
@Timeshifter: The scroll shows when needed, which is more useful for mobile.
In case you aren't aware, there are other sticky styles besides this one:
I recall there was a "mw-sticky" class too unless they removed it.
I wouldn't assume "col1left" followed or was aware of the guidelines at the time, the same way I wasn't when I first created the covid styles. If you weren't aware, "sticky-col1" and "sticky-col2" are used on the covid styles. You want "highly likely to be unique to the template being used", which templateName-style accomplishes. This template's classes already follow guidelines by being named "sticky-header-...", so I don't see a need to deviate from it:
  • sticky-header
  • sticky-header-multi
  • sticky-header-scroll
  • sticky-header-col1
  • sticky-header-col2
Also, my preference would be to change the "sticky-header" class to "sticky-header-row" so it describes it better. Another thought is that the template could be better described if named "Sticky table" instead of "Sticky header". Jroberson108 (talk) 23:08, 7 July 2024 (UTC)[reply]

When I do google searches "sticky header" is used when the discussion is ongoing. "Sticky table header" is used to introduce the topic. Same for "Sticky table". Since this template goes above a table there is no need to put "table" in the template name.

I dislike longer class names, but there is something to be said about the simplicity of class names that all start with "sticky-header". And I did not realize the number of sticky templates (not just for tables) on and off English Wikipedia.

sticky-header-row sounds good in order to clearly distinguish it from sticky-header-col1 and sticky-header-col2.

So are we going with scroll on or off by default? I think it should be off by default so that article editors can decide for themselves. I have already been thanked for an article with 3 long tables that I converted to scroll windows (via {{sticky header}}) a few days ago. So I think this template will be very popular with editors, but I don't think we should force the scroll window on them at first. They will applaud it after having to scroll through long tables at first. --Timeshifter (talk) 11:20, 8 July 2024 (UTC)[reply]

More accurately, this template styles various parts of a table, the table, and the table's wrapper div. Generally the CSS is included above or better in thead. The "style" import template styles table parts only, if I recall, or headers (h1-h6) aka page sections, and can probably be added to anything else too like images or a paragraph notice. The point is that table's aren't the only element considered to have headers. I'm fine with "sticky-header" or "sticky-table". My preference is the latter.
The scroll is automatic. The browser adds scrollbars only when necessary. Nothing for the editors to worry about. That's how the covid styles and this template's sticky-header-scroll class work too. Jroberson108 (talk) 13:52, 8 July 2024 (UTC)[reply]

Let the other sticky headers distinguish themselves with template names like "Sticky image" or "sticky header image" or whatever. We keep "Sticky header start" for our template name. People are more familiar with the name "sticky header" versus "sticky table" on Wikipedia. Plus it makes it easier and more intuitive to convert the {{sticky header}} tables to the new scroll window tables.

OK, I understand that the scrollbars are automatically off or on depending on how the table fits in the screen.

My question was/is whether the scroll window has to be added via the sticky-header-scroll class being added to the new template. That is what I want. And I assume that is the case, since the class is in your list:

  • sticky-header-row
  • sticky-header-multi
  • sticky-header-scroll
  • sticky-header-col1
  • sticky-header-col2

I just wanted to make sure the scroll window wasn't added without the sticky-header-scroll class being added to the new template.

I suggest having class=sticky-header and class=sticky-header-row do the same thing. That would make it even easier to convert {{sticky header}} to the new template. Most of the {{sticky header}} tables use class=sticky-header. And sticky-header-multi is the same on both templates. So this basic change would be easy and intuitive: 

{{sticky header}}
{| class="wikitable sortable sticky-header"

to 

{{sticky header start}}
{| class="wikitable sortable sticky-header sticky-header-col1"
...
{{sticky header end}}

Or would that cause problems with having the same class name in 2 different templates on the same page? Which is possible if one only converts one table to the new template, and leaves other tables with the old template for later conversion (if ever). I have a feeling it would be a problem. Unless the start/end aspects of the new template prevent it from seeing those duplicate class names elsewhere. --Timeshifter (talk) 15:13, 8 July 2024 (UTC)[reply]

Maybe "sticky-header-multi" should be changed too since it doesn't indicate row or column.
The CSS include and <div class="sticky-header-scroll"> are added via {{Sticky header start}}. Nothing for the editors to decide.
Having duplicate classes complicates the CSS, testing, and documentation. You can see how much is there already, which doesn't include col1 and col2. This is a new template that is used differently, so familiarity isn't an issue and we can pick the best template and class names for long term use that describes things better. I think "sticky-table-col1", etc. makes more sense. Tables have columns, which may be header cells (th) or data cells (td). Headers are generally known as page sections (h1-h6). Again, either can work. This just makes more sense to me.
In time, all uses of {{Sticky header}} will be converted before deletion. If the classes change, then it isn't a big change. From our prior discussions on TfD, we don't need to worry about converting since they handle it and have tools to help. Jroberson108 (talk) 15:53, 8 July 2024 (UTC)[reply]
If I search all the Village Pump archives I get 12 sections with "sticky table" and 28 with "sticky header". Page sections (h1-h6) are known as headings. At least according to this Google search:
https://www.google.com/search?q=page+sections+%28h1-h6%29.
We used class=sort-under and class=sort-under-right to mean the same thing for use with {{sort under}}. And my understanding from that discussion was that it was not technically difficult to set up.
I disagree with all tables using this new template to have a possible scroll window without manually adding a class: "Nothing for the editors to decide."
If you are saying that it is technically difficult to provide a choice, then I understand. In that case we can go ahead with this new template, and maybe create another template for fully-sticky headers (row and column) without scroll windows.
I think we need more input on all of the above. More input has helped in the past with the various templates. --Timeshifter (talk) 17:07, 8 July 2024 (UTC)[reply]
Technically h1-h6 are called headings, but can sometimes be referred to as headers as I did. If you want to be precise, <th> are called header cells, not headers. There is also a <header> tag.
"I disagree with all tables using this new template to have a possible scroll window without manually adding a class ..." Sounds like what is already in this template, so no changes needed then. It hasn't been a problem on the covid styles. Anyways, feel free to discuss with others. Jroberson108 (talk) 17:44, 8 July 2024 (UTC)[reply]

{{sticky header}} is used on the table in List of countries by intentional homicide rate. But there is no short scroll window of the type we are talking about in the Covid CSS tables unless one manually adds the class for it. And even with the Covid CSS tables it is possible to remove the short scroll window by removing the scroll div:

<div class="scroll-container">

See this short scroll-window table:

For example, I removed it from the above-linked table. 

<templatestyles src="COVID-19 pandemic data/styles.css"/>
<div class="covid19-container" role="region" tabindex="0">
{{mw-datatable}}{{sort under}}{{table alignment}}
{| class="wikitable sortable mw-datatable defaultcenter col1left sort-under-center sticky-col1" style="margin:0; font-size: 90%"
Player Titles Dub Doh Ind Mia Mad Rom Can Cin Wuh Bei Boc Cha Ber San Phi Mos Tok Zur Years
United States Serena Williams 23 - - 2 8 2 4 3 2 - 1 - 1 - - - - - - 1999–2016
Switzerland Martina Hingis 17 - - 1 2 - 2 2 - - - - 2 1 - - 1 5 1 1997–2007
Germany Steffi Graf 15 - - 1 3 - - 2 - - - 1 1 5 - 1 - 1 - 1990–1996
Russia Maria Sharapova 14 - 1 2 - 1 3 - 1 - 1 - - - 2 - - 2 1 2005–2015
United States Lindsay Davenport 11 - - 2 - - - - - - - - - - 1 - - 4 4 1997–2005
Belgium Justine Henin 10 - - 1 - - - 2 - - - - 2 3 - - - - 2 2002–2007
Belarus Victoria Azarenka - 2 2 3 - - - 2 - 1 - - - - - - - - 2009–2020
Poland Iga Świątek - 2 2 1 1 3 - - - 1 - - - - - - - - 2021–2024
Spain Conchita Martínez 9 - - - - - 4 - - - - - 2 2 - 1 - - - 1993–2000
United States Monica Seles - - - 2 - 2 4 - - - - - 1 - - - - - 1990–2000
United States Venus Williams 2 - - 3 - 1 - - 1 - - 1 - - - - - 1 1998–2015
Romania Simona Halep 1 1 1 - 2 1 3 - - - - - - - - - - - 2014–2022
Czech Republic Petra Kvitová - 1 - 1 3 - 1 - 2 - - - - - - - 1 - 2011–2023
Belgium Kim Clijsters 7 - - 2 2 - 1 1 1 - - - - - - - - - - 2003–2010
Spain Arantxa Sánchez Vicario 6 - - - 2 - 1 2 - - - - 1 - - - - - - 1992–1996
France Amélie Mauresmo - - - - - 2 2 - - - - - 2 - - - - - 2001–2005
Serbia Jelena Janković - - 1 - - 2 - 1 - - - 1 - - - 1 - - 2007–2010
Denmark Caroline Wozniacki 1 - 1 - - - 1 - - 2 - - - - - - 1 - 2010–2018
Argentina Gabriela Sabatini 5 - - - - - 2 - - - - 1 2 - - - - - - 1991–1992
France Mary Pierce - - - - - 1 - - - - - 1 - 1 - 2 - - 1997–2005
Russia Dinara Safina - - - - 1 1 1 - - - - - 1 - - - 1 - 2008–2009
Poland Agnieszka Radwańska - - - 1 - - 1 - - 2 - - - - - - 1 - 2011–2016
Belarus Aryna Sabalenka - 1 - - 2 - - - 2 - - - - - - - - - 2018–2023
Player Titles Dub Doh Ind Mia Mad Rom Can Cin Wuh Bei Boc Cha Ber San Phi Mos Tok Zur Years

So are you saying that with the new template, the short scroll window will be implemented by adding a class manually?

I just noticed that the above table is not top sticky until a horizontal scroll bar shows up when I narrow the table enough.

So I guess the new template will only work correctly when there is no choice given about the short scroll window. The short scroll window will have to be built-in. --Timeshifter (talk) 18:25, 8 July 2024 (UTC)[reply]

OK. After sleeping on it, I can live with {{sticky table}}. Since this template has a short scroll window, and {{sticky header}} does not, we need a template name that makes it clear that this template is different in a major way. It may be slightly more time-consuming to convert from one to another though.
Possible classes:
sticky-table-row
sticky-table-rows or sticky-table-multi or sticky-table-multi-rows
sticky-table-scroll - Built-in. Not added manually.
sticky-table-col1
sticky-table-col2
Please clarify this for me. Editors won't see sticky-table-scroll in the table wikitext? And there will be no option (for now) to not use the short scroll window? There will no longer be long tables outside a short scroll window?
--Timeshifter (talk) 10:20, 9 July 2024 (UTC)[reply]
"sticky-table-scroll" will be in the div above the table, which is transcluded by the {{sticky table start}}. The transclusion code is all they see.
If this template is being kept, then naming the new templates like this will follow guidelines on ensuring the class names are unique.
"sticky-table-row" and "sticky-table-rows" could work. The former could also be "sticky-table-row1" like col1 and col2. Be nice if some other editors joined the discussion. Jroberson108 (talk) 15:58, 9 July 2024 (UTC)[reply]
So editors only see {{sticky table start}} which is what you mean by "transclusion code" I assume. That is a new phrase for me. I just called them template names.
sticky-table-row1 could work.
For more than one row of column headers:
sticky-table-rows. Since column headers can have more than 2 rows.
Pinging: TheDJ. Qwerty284651.
--Timeshifter (talk) 19:43, 9 July 2024 (UTC)[reply]
"sticky-table-rows" would only work on the thead element, which is how multi works on this template. Sortable and the sticky gadget are the only two that move rows into the thead. Jroberson108 (talk) 19:59, 9 July 2024 (UTC)[reply]

I didn't understand any of that. :)

Does the Covid CSS work with multi-row headers? If so, are there any sticky multi-header-row table examples you can link to that use the Covid CSS? I want to look at the wikitext. I haven't looked at the HTML yet. --Timeshifter (talk) 22:41, 9 July 2024 (UTC)[reply]

The covid css does not. Jroberson108 (talk) 23:00, 9 July 2024 (UTC)[reply]
Retrieved from "https://mdwiki.org/wiki/Template_talk:Sticky_header"