Template talk:Sticky header

Archives

This page has archives. Sections older than 90 days may be auto-archived 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]

Does Android info need to be updated in "known issues"

User:Jroberson108. I noted that sticky tables do not work at all (no matter the width) in my iPhone SE 2020 in Safari, Firefox, Chrome, Edge, and Opera browsers.

See page of narrow sticky tables for testing in cell phones, etc.

What's happening in Android? Does the Minerva issue effect Android the same way? Or does sticky still work at times? --Timeshifter (talk) 03:11, 10 May 2025 (UTC)[reply]

The changes they made to Minerva causes it to not work at all. Jroberson108 (talk) 03:24, 10 May 2025 (UTC)[reply]

So in your Android phone sticky headers do not work no matter the width of the table? Have you tested in Firefox, Chrome, Edge, and Opera browsers? If so, I think we should put that new Android info in the Minerva section of "Known issues".

--Timeshifter (talk) 03:34, 10 May 2025 (UTC)[reply]

I updated the Minerva info. I assumed {{sticky header}} is not working at all on your Android phone at any table width. I discovered that mobile sticky works fine with {{sticky table start}}. --Timeshifter (talk) 19:07, 12 May 2025 (UTC)[reply]

I encountered the same problem. On Android (e.g., in Chrome), {{sticky header}} works if you not using the mobile version of an article. However, if you using the mobile version, it actually doesn't work. Not only on Android, but also on Windows... Here's an example of an article with a long table (the first one in the article) using the template.

https://en.wikipedia.org/wiki/All-time_Olympic_Games_medal_table -> working
https://en.m.wikipedia.org/wiki/All-time_Olympic_Games_medal_table -> not working

Miria~01 (talk) 12:35, 1 June 2025 (UTC)[reply]

@Miria~01: I see what you are saying. Does anybody look at the mobile skin Minerva on desktop PCs? Or tablets? How many people? And why? --Timeshifter (talk) 14:48, 1 June 2025 (UTC)[reply]

Rereading the discussion, I see that my post didn't reveal any new information. I thought Android always runs the Minerva skin, even if you change the URL for a mobile-friendly website by removing the "m." before the domain name. But the skin changes then, too, and that's why it works on Android (Chrome, Firefox etc.).

Regarding your question: the number of people using Minverva on desktop PCs is probably negligible. Miria~01 (talk) 15:14, 1 June 2025 (UTC)[reply]

Templates with implemented {{sticky header}}

Hello, I would like to ask for your help or advice for a small problem. Template:Medals table has implented {{sticky header}} in their code (...local sticky = frame:extensionTag{ name = "templatestyles", args = {src = "template:sticky header/styles.css) and it works perfectly and is a great addition. However, there are also very long tables, and it would be good if they were scrollable in a container like {{sticky table start}}. In All-time Olympic Games medal table, we even have three long tables one after the other, and that's not good. Therefore, I tried wrapping them in a container (see my User:Miria~01/sandbox2) with
div style="overflow-y:auto; max-height: 50vh; max-width: max-content; font-size:90%". Unfortunately, the sticky headers jump in the container itself when the media screen is scrolled. Is there perhaps a workaround without having to adopt the properties of {{sticky table start}} globally for all tables with the Template:Medals table? Miria~01 (talk) 12:08, 18 June 2025 (UTC)[reply]

@Miria~01: In the Vector (2022) and Timeless skins at certain widths, there are other top-sticky elements that appear at the top of the page and will hide/obstruct the table headers when the headers are top-sticky too. In those instances, this template shifts the headers below the competing elements. Because you added an element around the table that the headers can stick to, the headers stick to the top of that instead of the page, but the adjustment still occurs. {{Sticky table start/end}} is made with a similar element around the table, but without that adjustment since it will never stick to the top of the page.

As far as a fix goes, because this is done through {{Medals table}}, adding inline styles to the article cannot fix it. Adding page-level styles to that article might override the top values by setting them to 0? However, I suspect since {{Medals table}} used this template and not the other, there is consensus or at least a desire from the developer(s) to have headers stick to the top of the page and not a wrapper element. I suggest asking there if they want to switch to using {{sticky table start/end}} or maybe add a template flag so editors can choose which sticky template to use. Jroberson108 (talk) 16:08, 18 June 2025 (UTC)[reply]

Thanks for the answer. Actually, I proposed implementing this for the template in August 2024 (before that, I was unaware of {{sticky table start}}. However, I saw that many users in other sport tables had switched from {{sticky table start}} to {{sticky-header}} and wanted to look for a custom solution first. I'll ask later whether there's a consensus to switch it at {{Medals table}}.

Can I ask what you mean by "add a template flag"? Do you mean an additional parameter in the {{Module:Medals}} table specifying which .css file should be used at the template and by default, if the parameter isn't specified, sticky-header could still be used. Miria~01 (talk) 16:55, 18 June 2025 (UTC)[reply]

Just for your information, with these changes in {{Template:Medals table}}, this switch would work, tested with Module:Sandbox/Miria~01/2 on User:Miria~01/sandbox2 with {{#invoke:Sandbox/Miria~01/2|createTable|style=alt for the first table and for the second table with {{#invoke:Sandbox/Miria~01/2|createTable. These would be the changes in {{Module:Medals table}}

local stylesheet = args['style']
local sticky = frame:extensionTag{ name = "templatestyles", args = {src = "template:sticky header/styles.css" } }
local sticky
if stylesheet == 'alt' then
        sticky = frame:extensionTag{ name = "templatestyles", args = {src = "template:sticky table start/styles.css"} }
else
sticky = frame:extensionTag{ name = "templatestyles", args = {src = "template:sticky header/styles.css"} }
end
...
...
if stylesheet == 'alt' then
root:addClass('sticky-table-head')
else
	   root:addClass('sticky-header-multi')
end
		root:css('text-align', 'center)

...
...

if stylesheet == 'alt' then
  local container = mw.html.create('div')
  :addClass('sticky-table-scroll')
  :wikitext(tostring(root))

  local outerContainer = mw.html.create('div')
  :addClass('sticky-table-collapsible')
  :node(container)
 return header .. sticky .. tostring(outerContainer) .. footer
else
return header .. sticky .. tostring(root) .. footer
end
end

@Miria~01: It would be a template parameter that the module would use. See WP:PARAMETER. The logic is mostly correct, although what changes for "sticky table start" is the css file, table class, and adding the same divs around the table to match what that template does.

Better would be to include {{sticky table start}} and {{sticky table end}} above and below the table so the css include and divs exist in one location, but not sure if possible since the elements are built in the module instead of printing out tags from a string. Jroberson108 (talk) 18:54, 18 June 2025 (UTC)[reply]

Miria~01. I will not have time to help, but I thought I would point out that you need a background color for your username in your signature in dark mode. In dark mode I can't see "Mir" since it is black text on a black background.--Timeshifter (talk) 16:12, 18 June 2025 (UTC)[reply]

thanks, I changed that directly. Miria~01 (talk) 16:27, 18 June 2025 (UTC)[reply]

@Jroberson108: A little info, I just saw (by accident, because I had implemented it that in my sandbox for a table) that {{sticky table start}} works with {{sticky header}}. But that wasn't the case a week ago, and I also noticed that no changes have been made to the code (neither for sticky table start, sticky header, nor Module:Medals table). I implemented that into the tables in the described article and it now fits and there are no jumps (see here).

<div style="font-size:90%">
{{sticky table start}} 
{{Medals table
 | caption        =
 | host           =
 | remaining_text =
 | show_limit =
 | team           = {{Tooltip|NOC|National Olympic Committee}}
 | flag_template  = flagIOC
 | event          = Summer
 | gold_USA = 1105| silver_USA = 879 | bronze_USA = 781
 ...
|}
{{sticky table end}}

Miria~01 (talk) 22:50, 26 June 2025 (UTC)[reply]

@Miria~01: That puts the table that is already sticky from this template in a scrollable box styled by {{sticky table start}}. Technically, the two templates shouldn't be used together due to competing styles. They are two separate templates to try to accomplish a similar style. It appears to be working, at least in the default desktop skin, but that may not always be the case since they are developed independent of each other. It would be best if one or the other were used. Jroberson108 (talk) 11:01, 28 June 2025 (UTC)[reply]

It also works on the Minerva skin (mobile), but you're right, it's not an ideal solution. Miria~01 (talk) 11:59, 28 June 2025 (UTC)[reply]

Missing borders

The sticky-header and sticky-header-multi classes cause the bottom row and rightmost column to lack, respectively, bottom and right borders. Normal table:

Heading	Heading
Cell	Cell
Cell	Cell
Cell	Cell

With sticky-header class:

Hairy Dude (talk) 09:35, 22 July 2025 (UTC)[reply]

@Hairy Dude: Which browser, device/OS and skin so I can try to reproduce the issue? Borders are recreated due to them missing in Windows Firefox.

I tested all my Windows 10 browsers (Chrome, Edge, Brave, Firefox) with Vector 2022 skin, no issues. Android Chrome/Firefox with Minerva skin: landscape no issues, but portrait shows the table (not cells) missing a right and bottom border. Jroberson108 (talk) 10:32, 22 July 2025 (UTC)[reply]

To editor Hairy Dude: - all borders displayed in light and dark mode for me! (Safari 14, macOS 11, Vector 2022 skin, 'sticky headers' gadget disabled). - Asdfjrjjj (talk) 05:12, 29 July 2025 (UTC)[reply]

Seems to be fixed now. Hairy Dude (talk) 12:54, 1 August 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]