Template talk:Sticky header

Archives

This page has archives. Topics inactive for 90 days are automatically archived 1 or more at a time by if there are more than 5.

Sticky headers mobile problem

Hello not sure if you are aware but all the lists for games that use sticky headers in the mobile version are not working. When on the mobile version I cant scroll to the right it is just stuck and fixed into that position?

Please help. NakhlaMan (talk) 02:59, 18 March 2025 (UTC)[reply]

@NakhlaMan: I moved your question to the related talk page. From your contributions, I believe you are asking about List of Sega Genesis games#Licensed games. Lastly, which phone and browser are you using? Jroberson108 (talk) 05:49, 18 March 2025 (UTC)[reply]

In testing [1] on Windows 10 Chrome, it does look like the mobile version stopped working. There must have been some changes they made to the global styles. I'll have to take a closer look. Jroberson108 (talk) 06:17, 18 March 2025 (UTC)[reply]

On mobile, the parent container <div id="mw-mf-page-center"> has an overflow: hidden; style applied to it, which makes this template not work. I'm still looking into it. Jroberson108 (talk) 07:11, 18 March 2025 (UTC)[reply]

Looks like the style was added to fix some issues per [2]: Without this the page actions and user dropdowns in advanced mobile mode or desktop mode will create a horizontal scrollbar. Jroberson108 (talk) 07:27, 18 March 2025 (UTC)[reply]

Mentioned at phab:T387768. Jroberson108 (talk) 21:07, 18 March 2025 (UTC)[reply]

@NakhlaMan: Since sticky doesn't work on Minerva (mobile) anymore, I removed the override so that wide table scrolling works again, at least when the screen is 639px wide or less. There is still an issue where the scrolling doesn't work on wider screens, but that is outside the scope of this template (see phab:T388986). Jroberson108 (talk) 19:22, 19 March 2025 (UTC)[reply]

FYI: {{sticky header}} works again on the Minerva skin, if the width of the screen is not too small. Miria~01 (talk) 18:52, 12 July 2025 (UTC)[reply]

@Miria~01: Reverted changes. Should work on smaller screens again like before. Jroberson108 (talk) 23:36, 12 July 2025 (UTC)[reply]

@Jroberson108: Not sure since when it's broken again. As of today, it does not work on mobile. —CX Zoom[he/him] ^{(let's talk • {C•X})} 07:16, 19 September 2025 (UTC)[reply]

@CX Zoom: See Template:Sticky header#Known issues, specifically the third and fourth points on <=639px width screens and Android zoom. It is not sticky when the screen is <= 639px wide, which is more likely in portrait orientation, but is sticky when wider like in landscape orientation or if portrait is wider than 639px. I'm on Android and it is not sticky in portrait, but is sticky in landscape only when you zoom out to see the entire page. I would assume iPhone works the same except without the need to zoom out as far as testing went in the past. Jroberson108 (talk) 13:56, 19 September 2025 (UTC)[reply]

Thanks for clarifying. But, if I remember correctly, it used to work fine on mobile a few months ago? —CX Zoom[he/him] ^{(let's talk • {C•X})} 10:06, 20 September 2025 (UTC)[reply]

@CX Zoom: I'm not sure which phone you have? On Android in portrait orientation, there was always layout and zoom issues on the entire page if at least one wide table used this template causing readability issues. In landscape orientation, those issues still exist, but are minimal due to the wider screen width. The global CSS for mobile has a breakpoint at <=639px where they change the table and caption elements to blocks, which makes the sticky headers not work both on this template and the sticky gadget, but the global CSS does add horizontal scrolling to tables and fits them within the main content area to resolve layout issues. Jroberson108 (talk) 15:15, 20 September 2025 (UTC)[reply]

Thanks, I must have confused it some other mode/device. Is there any personal CSS code that we can apply to force a view on portrait mode? Can you please share it? Thanks! —CX Zoom[he/him] ^{(let's talk • {C•X})} 05:23, 21 September 2025 (UTC)[reply]

@CX Zoom: User:Jroberson108/StickyTableHeadersFix should make table headers sticky for this template and the gadget on smaller screens with the issues listed there. Jroberson108 (talk) 18:28, 21 September 2025 (UTC)[reply]

Thank you very much! Seems to work fine for me also (Android on Samsung). You could also add it to the documentation just in case anyone else needs it. —CX Zoom[he/him] ^{(let's talk • {C•X})} 16:14, 22 September 2025 (UTC)[reply]

@CX Zoom: Are you saying you don't have sticky wide table issues on your Android in portrait orientation? Which phone are you using? I have issues on my Samsung Galaxy S21 5G. Test Template:Sticky header/testcases#Test wide (single row, sticky). The table in the section above it shows how the table is when not sticky. Jroberson108 (talk)

Sorry, I did not write the whole thing. Yes, the table exceeds the normal content area, so I have to scroll beyond it to view the rest of the table. But there are no zoom issues, so the text (inside and outside the table) is readable, no abnormal font sizes. —CX Zoom[he/him] ^{(let's talk • {C•X})} 21:45, 23 September 2025 (UTC)[reply]

@CX Zoom: Sounds like you confirmed the same layout issue. You don't need to zoom out to view the entire table before the headers are sticky? That's what I have to do, which makes the font size smaller for the entire page and harder to read. Jroberson108 (talk) 01:43, 24 September 2025 (UTC)[reply]

I don't need to zoom out. The zoom at pageload is same as the default, and aligns with the normal content area. To view the wide tables, however, I have to scroll horizontally. I am also unable to zoom in or out even if I want to, which was the case with mobile version of Wikipedia even before installing the script. —CX Zoom[he/him] ^{(let's talk • {C•X})} 16:08, 24 September 2025 (UTC)[reply]

@CX Zoom: Ok, so sticky headers works for you without having to zoom out. Which phone are you using? Maybe something changed? Jroberson108 (talk) 16:38, 24 September 2025 (UTC)[reply]

Galaxy F14 5G (rebranded version of Samsung Galaxy M14 5G). Android 15. Checked with Chrome & Edge. —CX Zoom[he/him] ^{(let's talk • {C•X})} 16:43, 24 September 2025 (UTC)[reply]

@CX Zoom: Galaxy S20 FE 5G also requires zooming out for sticky to work. After talking with three AIs to diagnose the issue, seems to be a hardware difference and how it affects calculations (ex. AMOLED vs. LCD). No clear answers. I updated the issues on the doc. Thanks for your help in testing. Jroberson108 (talk) 21:11, 24 September 2025 (UTC)[reply]

Template and Wikipedia "sticky" gadget

Possibly minor UI stuff (on Safari 14.1.2, macOS 11.6, Vector 2022 skin):

if the "sticky" testing and development gadget is not enabled, then {{sticky}} makes headers appear offset (not flush) from the top of the website (eg),
if the "sticky" gadget is enabled, then:

headers of tables without {{sticky}} appear flush with the top of the website (eg),
headers of tables with {{sticky}} appear all over the place (eg).

Wonder if there's a way to prevent this? Or else maybe we oughtta rec the sticky gadget in favour of this template ..? Or no action needed, it's just UI anyways :) - Asdfjrjjj (talk) 20:42, 6 August 2025 (UTC)[reply]

Ps or maybe is just a browser/OS thing, dunno - Asdfjrjjj (talk) 20:44, 6 August 2025 (UTC)[reply]

@Asdfjrjjj: Thanks for the images, they really help. In all your tests, the site's top header bar is shown, so browser width is at least 1120px, which is where adjustments are added by this template and the gadget to shift the top-sticky table headers under the bar. Looks like you tested this template's doc, Fourth voyage of Columbus#Ships, and Wikipedia:WikiProject Belize/Guidance.

In testing Template:Sticky_header#Single sticky header row, which appeared in your first test, I don't have any issues with or without the gadget on Windows 10 Chrome/Edge/Brave (Blink engine) or Firefox (Gecko engine) browsers. On Android Chrome and Firefox in landscape zoomed out with or without gadget, no issues, although it isn't wide enough to show the site's top header bar. I don't have Apple products, so can't test Safari, which all macOS browsers use the WebKit engine.

This is what I see in your logged-in tests:

Test #1: (template, no gadget), all are sortable using the "sticky-header" class. All are top-sticky with a consistent small gap from top.
Test #2.1: (no template, gadget), all are not sortable. All are top-sticky and flush to the top.
Test #2.2: (template, gadget), all are sortable and using the "sticky-header" class. All are top-sticky with a consistent small gap from top, but the prior table's top-sticky headers are still visible with a larger gap from the top even though its table is no longer on screen. The exception of the small gap is image #2, where it is flush for some reason.
- Image #1: "Notability" and "Verifiability" subsection tables in "Before drafting" section. Looking at "Verifiability" table, but not scrolled up enough to make its headers sticky. "Notability" headers still visible with large gap from top (bottom-sticky?).
- Image #2: "Verifiability" subsection table in "Before drafting" section followed by "Style guideline" table in "Drafting" section. Looking at "Style guideline" table, which its headers are top-sticky and flush (why flush?). "Verifiability" headers still visible with gap from top.
- Image #3: "Layouts" and "Templates" subsection tables in "Drafting" section. Looking at "Templates" table, which its headers are top-sticky with gap from top. "Layouts" headers still visible with gap from top.

Does the issue occur when using the "sticky-header-multi" class like in Template:Sticky header#Sorttop versus sortbottom?

Can you log out and verify if the issue still occurs for these two (template, no gadget):

This way we can rule out any other gadgets, configurations, and user styles/scripts that might be affecting it? I looked at your user styles/scripts and didn't see anything that might interfere.

Is it still an issue if the site's top bar is not top-sticky, i.e. browser slightly less than 1120px wide? Jroberson108 (talk) 01:23, 7 August 2025 (UTC)[reply]

For the same browser, OS, skin, user logged in, "sticky" gadget enabled:

issue does not occur in "sticky-header-multi" tables in Template:Sticky header#Sorttop versus sortbottom (all headers flush with top bar, no misplaced/vertically-offset headers).
issue still occurs in Wikipedia:WikiProject Belize/Guidance and this template's doc when browser is slightly narrrower than 1120px (some headers were now flush with browser's top bar, but some weren't, and all headers were misplaced/vertically-offset after scrolling).
issue does not occur in Wikipedia:WikiProject Belize/Guidance if I swap in "sticky-header-multi" class for "sticky-header" (with rowspan=2 for headers; all headers flush with top bar, no misplaced/vertically-offset headers).

For the same specs, but user logged out:

issue still occurs in Template:Sticky header#Single sticky header row regardless of browser width (offset header).
issue does not occur in Template:Sticky header#Sorttop versus sortbottom nor in any "sticky-header-multi" table (flush headers, no errant headers).
issue still occurs in Wikipedia:WikiProject Belize/Guidance regardless of browser width, but only in tables with "sticky-header" class (only offset headers, no errant headers seen this time).

For same OS and user logged out, but this time in Chrome [138.0.7204.184 (Official Build) (x86_64)]:

issue does not occur in Wikipedia:WikiProject Belize/Guidance regardless of browser width and regardless of sticky class (no offset headers anywhere, no errant headers anywhere).
ditto for this template's doc.

For same OS and Chrome, but this time user logged in ("sticky" gadget enabled):

no issues anywhere in Wikipedia:WikiProject Belize/Guidance regardless of browser width and regardless of sticky class (all headers flush, no errant headers).
ditto in this template's doc.

So that settles it I think - it's for sure Safari 14's fault, looks like? Maybe issue doesn't come in newer Safari versions though! Or just use "sticky-header-multi" class as a sort of stopgap for the few users on old Safaris! I'm pretty sure this answers my q, thank you Jroberson108 :) - Asdfjrjjj (talk) 02:21, 7 August 2025 (UTC)[reply]

@Asdfjrjjj: So the issue is only in Safari (not Chrome) regardless of browser width, logged in/out, and only when this template's first row is sticky, but not when thead is sticky.

Seems like the gadget's sticky thead is being added on to the template's sticky row. I removed the conflicting gadget styles from this template, which should help resolve some of it, at least on the first page. Can you retest these logged in with gadget?

The gap when logged out (no gadget, no other top-sticky elements) will probably still be present. It is most likely a layout bug in how Safari 14 calculates sticky positioning for rows relative to the table's edge, not the viewport top according to my research. There are updates to Safari 15[3] that relate to the calculation, but no way to verify if fixed without testing. Based on your macOS 11.6, you are on the latest Safari version, so not sure if an OS upgrade is possible? Otherwise, Chrome seems to be your best bet. Jroberson108 (talk) 10:11, 7 August 2025 (UTC)[reply]

Tests:

logged in with gadget enabled (old OS, old Safari): no issue for "sticky-header-multi" tables; issue still present for "sticky-header" tables, but this time only a gap between table header and website's top bar, so no displaced headers (that I could see)!
logged out (old OS, old Safari): same as above^
logged in with gadget enabled (macOS 11.7.10, Safari 16.6.1): no issue with any sticky class!
logged out (macOS 11.7.10, Safari 16.6.1): same as above^

Thank you for fixing the displaced headers, Jroberson108! The gap only shows up on old Safari, will just upgrade prolly :) - Asdfjrjjj (talk) 22:10, 7 August 2025 (UTC)[reply]

@Asdfjrjjj: No problem. Thanks for the testing. Glad to know you could upgrade and it works. I added the issue to the doc. Jroberson108 (talk) 01:32, 8 August 2025 (UTC)[reply]

Incompatible with overflow:auto

It looks like this template is incompatible with style="overflow:auto;", which is a really helpful piece of code to keep horizontal scrolling limited to the table, not the entire page. See Wikipedia:User groups#Table for an example use in the wild; try narrowing your screen, removing <div style="overflow:auto;"> from Wikipedia:User groups, and then clicking show preview (rather than publishing the edit) to see the problem. A fix to make these compatible would be very much appreciated :) House Blaster (talk • he/they) 19:45, 18 September 2025 (UTC)[reply]

@HouseBlaster: There is more info here:

Help:Table#Overflowing tables.

Template:Sticky header#Known issues.

Jroberson108 may be able to help.

--Timeshifter (talk) 19:54, 18 September 2025 (UTC)[reply]

@HouseBlaster: {{sticky table start}} may be a better solution for the source table:

Template:User access levels

--Timeshifter (talk) 20:02, 18 September 2025 (UTC)[reply]

Thanks Timeshifter! I am extremely reluctant to use {{sticky table start}}, because that has the effect of making it harder to see the table, even on large screens. I guess it is a pick your poison situation... hmmm. Would it be possible to get a version of {{sticky table start}} with only the horizontal scrolling? House Blaster (talk • he/they) 20:07, 18 September 2025 (UTC)[reply]

{{Sticky table start}} talk continues at Template talk:Sticky table start#Remove vertical scroll. Jroberson108 (talk) 22:03, 18 September 2025 (UTC)[reply]

Small bug losing thin line between header of 1st row of data

Sticky has been added to List of Kappa Alpha Order chapters. When first loaded, there is a darker thin line between the header and the first row of data (the same as those between lines of data) after scrolling down and back up, it is no longer there. I've noticed that on others that I have added this on. Not sure if I'm using incorrectly or if it can be fixed. I know there are some things like changing order with tables with combined cells where after operations you can't restore the original, but I'd hope this could be done here.Naraht (talk) 09:43, 1 December 2025 (UTC)[reply]

@Naraht: As I recall, borders have been fixed as much as they could be. Anything further was a complete redo and reversal of the application, which caused other borders to go missing. Jroberson108 (talk) 14:48, 1 December 2025 (UTC)[reply]

Jroberson108 OK. WP:FRAT is likely to add this to approximately 300 articles (mostly of the type List of Omega Mu Omega chapters) which include tables of upwards of 500 rows. So if you want any place to have stress testing. :)Naraht (talk) 15:08, 1 December 2025 (UTC)[reply]

@Naraht: That would take it's usage up to ~7,400 pages, so I don't forsee any new issues. Jroberson108 (talk) 15:22, 1 December 2025 (UTC)[reply]

Jroberson108 Waiting on a few more comments on the wikiproject, but I've already tested my AWB editing for a subset.Naraht (talk) 15:25, 1 December 2025 (UTC)[reply]

Additional issue with notes/internal anchors.

On the fraternity chapter lists, we commonly use efn for notes and then stick a notelist below. When clicking on a list in the notelist, it moves to the correct row in the table, but that row is "under" the sticky row, and thus can't be seen. For example, go to List of Alpha Chi chapters, scroll down to the notelist and click the ^ next to d. It jumps so that the New York Kappa row is at the top of the visible area under the sticky header, *but* the row that the note is on is the one above that (Mount ida), under the sticky header.Naraht (talk) 14:11, 9 December 2025 (UTC)[reply]