Template talk:Sticky header

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Bolding[edit]

@Timeshifter: see MOS:BOLD:

To denote importance, seriousness, or urgency, you can also use the HTML element <strong>...</strong>, or the template {{strong}}. This way, the words can stand out for text to speech and other accessibility softwares.

— HouseBlaster (talk · he/him) 13:31, 31 January 2024 (UTC)[reply]

Concerning the bolding of: It only works on sortable tables.
The full paragraph at MOS:BOLD

Boldface (text like this) is common in articles, but is considered appropriate only for certain usages.

To create it, surround the text to be boldfaced with triple apostrophes ('''blah blah''').

To denote importance, seriousness, or urgency, you can also use the HTML element <strong>...</strong>, or the template {{strong}}. This way, the words can stand out for text to speech and other accessibility softwares.

I don't think this particular bolding is important, serious, or urgent enough to require strong tags. --Timeshifter (talk) 19:55, 31 January 2024 (UTC)[reply]
Timeshifter, <strong>...</strong> is part of the Semantic Web standards. Using ''' is meant for bolding without any emphasis at all. It is the wikitext equivalent to <b>...</b>, and you can read about the difference between <b>...</b> and <strong>...</strong> here. — HouseBlaster (talk · he/him) 20:19, 31 January 2024 (UTC)[reply]
OK, but it is still not important to use it here. If the MediaWiki developers thought it was important to make all bolding use strong tags in the rendered HTML, then they could make standard bolding (''') do that. --Timeshifter (talk) 23:19, 31 January 2024 (UTC)[reply]
"Standard" bolding does not include <strong>...</strong> because text is bolded for reasons other than emphasis. As just one example, we bold the name of the article in the lead. ''' is designed for use in those cases, but is not for use in emphasis. HouseBlaster (talk · he/him) 23:24, 31 January 2024 (UTC)[reply]
MediaWiki developers could continue to use <b>...</b> for headings in the HTML. They could use <strong>...</strong> in the HTML for '''. They could pick and choose. They haven't thought it important to use <strong>...</strong> in the rendered HTML for '''.
I don't think it provides info important enough for screen readers. It is a convenience for sighted readers. It is probably an annoyance to blind people using screen readers. Being interrupted all the time by notifications about the beginning and ending of bolded text.
Until I hear from blind editors with screen readers that they want it, then I am not going to use it. Go ask them. It's your turn. I asked them last time about your last idea. They didn't recommend it. --Timeshifter (talk) 01:12, 1 February 2024 (UTC)[reply]
Arguing about how ''' does not use <strong>...</strong> is nonsensical. It does not use <strong>...</strong> markup because it is not supposed to be used for emphasis (even though countless editors do so). I have opened a thread at Wikipedia talk:Manual of Style/Accessibility, because it is clear we will continue to disagree. HouseBlaster (talk · he/him) 01:30, 1 February 2024 (UTC)[reply]

Here are the discussions:

Most of the thread was against using strong tags. MOS:BOLD says it should rarely be done. And the semantic web is barely implemented and very problematic. And there is no button on the editing toolbar for strong tags, but there is one for bolding. --Timeshifter (talk) 02:56, 4 February 2024 (UTC)[reply]

Who in that thread opposed using strong tags? Isaacl said Conventional web best practice is to use semantic markup (which is <strong>...</strong>) rather than presentation-specific markup (which is <b>...</b>). Other editors said screen readers do no announce the start/end of bolding, but that has nothing to do with which tags should be used. HouseBlaster (talk · he/him) 03:23, 4 February 2024 (UTC)[reply]
I replied there again. Let us keep discussion there for now please to avoid duplication. Let it resolve further there. Ask your questions there. --Timeshifter (talk) 03:33, 4 February 2024 (UTC)[reply]

Template improvements[edit]

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[edit]

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[edit]

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 :)[edit]

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[edit]

@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]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Sticky_header&oldid=1220600611"