Template talk:Sticky table start

Neither id nor anchor worked properly inside table

Please see Template talk:Anchor#neither id nor anchor worked properly in one case. --Altenmann >talk 21:24, 7 May 2025 (UTC)

Column width problems

@Timeshifter: For the section you added at Template:Sticky table start#Column width problems, there is a solution, but it requires moving the vertical scroll bar to the far right edge of the main content area. When it is next to the table, each browser users its own calculations to try and figure out the width of the tables based on the contents, which is why there is premature wrapping of the text in some browsers like Firefox. Chrome apparently does it more accurately, which Edge also uses Chromium as of 2020 and is correct. This is not an issue on wide tables that are at or beyond the edge of the main content area where wrapping should occur. Personally, I think having the scroll bar to the far right would be better since no extra column widths are needed on narrow tables and mouse scrolling works in a larger area (table, scroll bar, and space between). Not a big deal if it doesn't change though. Jroberson108 (talk) 16:21, 28 June 2025 (UTC)

@Jroberson108: I see what you mean in Chrome and Edge. It is true in Opera, too. Since it is only a problem in Firefox (used by a small percentage of users), then it is not worth moving the vertical scroll bar all the way to the right. People aren't going to like that. Especially on narrower tables on big monitors. I think the scroll bar looks better adjacent to the table.

Maybe you or someone else will notify Firefox about this problem. Maybe someone already has done so.

--Timeshifter (talk) 15:40, 29 June 2025 (UTC)

@Timeshifter: Although I couldn't find this bug report, there are others reported that relate to Firefox's Gecko engine miscalculating things. On none iOS/iPadOS devices, Brave, Opera, and a few others use the Blink engine from the Chromium project just like Chrome. On iOS/iPadOS, pretty much all browsers including Safari, Chrome, Opera, Edge, Firefox use WebKit as required by Apple’s App Store policies with some possible exceptions in the EU. So iOS/iPadOS browsers might have the premature wrapping too, but I can't test on my Windows and Android devices.

Chrome and others using Blink appear to have at least ~65% of the pie with Safari and others using WebKit a big second at ~25%. Firefox still has 5.4% usage. Don't need to worry about the others at 0.1% or below. [1] Jroberson108 (talk) 18:14, 29 June 2025 (UTC)

On my iPhone SE 2020 I see the same thing in Safari, Firefox, Chrome, Edge, and Opera. The addition of style=width:Xem has no effect. The columns are all wrapped as far as the header text allows.

{{Sticky table start}} is working fine in all of those browsers. --Timeshifter (talk) 21:48, 29 June 2025 (UTC)

On my iPad 2020 the style=width:Xem column sizing is not needed in landscape view in Safari. The column text spreads out correctly since the table is not wider than the screen.

style=width:Xem is working in portrait view. The table is wider than the screen. It keeps the 2 columns in question from wrapping.

Otherwise, {{sticky table start}} works fairly well in Safari. Some problems on the farthest right of wide tables. Can drag over, but they bounce back a couple columns.

---

In Firefox the style=width:Xem column sizing is not needed in landscape view at 100% zoom setting (normal text size). The column text spreads out correctly since the table is not wider than the screen. Same is true for portrait view since the table fits in the screen due to the text being made automatically smaller.

At 150% zoom the column text of the 2 columns in question wrap due to the table not fitting in the screen in both landscape and portrait view. style=width:Xem only helps at 100 to 125% zoom and makes the browser choose to wrap the poll source column first.

Otherwise, {{sticky table start}} works perfectly in Firefox.

I will report back about the other browsers. --Timeshifter (talk) 23:03, 29 June 2025 (UTC)

@Timeshifter: I created a simple test here: Template:Sticky table start/testcases#Test premature wrapping. I found the premature wrapping on Firefox is only on Windows, not Android. Firefox on Android apparently uses a different engine called GeckoView. To clarify your prior testing, are you saying there is no premature wrapping on iOS/iPadOS browsers which all use WebKit? Jroberson108 (talk) 16:07, 30 June 2025 (UTC)

I added a fix for the Firefox premature wrapping on the template's sandbox. Can you verify it's fixed on Template:Sticky table start/testcases#Test premature wrapping? In 2023, someone mentioned that the fix may cause the scrollbar to always be visible in Safari although they were discussing the page scroll and not one for a smaller box like what this template does. Jroberson108 (talk) 17:23, 30 June 2025 (UTC)

I will be back later with more browser reports on iPad 2020.

But a quick check of Windows 11 Pro Firefox at Template:Sticky table start/testcases#Test premature wrapping shows no premature wrapping.

Firefox on iPhone SE 2020 when viewing Template:Sticky table start#Column width problems: I can't tell about premature wrapping because even at the lowest zoom level of 50% the table is jammed to the edge of the screen in landscape view. I need that 2-column table of your testcase sandbox but without the added CSS.

Firefox on iPhone SE 2020: With the added CSS in the testcases there is no premature scrolling. But there is also no scrollbar on the tall table. I can only see that part of the table that is first visible. Scrolling shows no more of the table. In both portrait and landscape view.

--Timeshifter (talk) 23:41, 30 June 2025 (UTC)

@Timeshifter: Interesting that there was no scrollbar and you couldn't scroll the table. Perhaps the entire table was visible and scrolling wasn't necessary? I reverted my sandbox change for your initial tests so that testcases works the same as live. Jroberson108 (talk) 02:15, 1 July 2025 (UTC)

Entire tall table was not visible with the added CSS on the testcases page. It was cut off. Page scrolling did not show more of the table. No right scrollbar.

Below are clean tables, not sandbox versions. And with 2-character dates, and long dashes. In order to allow more wrapping:

Short (no scroll)

Date	MoE
February 16–18	± 1.8%
February 13–16	± 1.8%

Tall (scroll)

Date	MoE
February 16–18	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 16–18	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%

In Firefox on Win 11 Pro I see premature wrapping in the taller scrolling table.

In iPhone SE 2020 I do not see any premature wrapping in the above 2 tables. I see a right scrollbar in the taller table but it is so narrow it is hard to see. --Timeshifter (talk) 03:57, 1 July 2025 (UTC)

@Timeshifter: We've established premature wrapping on Windows Firefox (Gecko engine). So your testing shows no premature wrapping on iOS/iPadOS browsers (WebKit engine). The thin scrollbar is apart of their design, which is the same on Android.

After the sandbox fix, it fixed the Windows Firefox premature scrolling and I found no issues with the other Windows and Android browsers, but you found scrolling didn't work anymore on the iOS/iPadOS browsers. Sound correct?

What version of Safari are you using? On Safari, I see some people reporting layout issues but not functionality issues, and they fix it with Javascript, but I can't use JS on templates. I'll look around more. I returned sandbox to using the fix. Jroberson108 (talk) 09:08, 1 July 2025 (UTC)

Safari 18.2+ supports the style [2] and scrolling should still work. I'm reading that on Safari, the scrollbar is not visible because they place it over the content (overlay), not to the side (gutter) like other browsers do, but becomes visible during scroll. If it were always visible, then it would cover the content. Are you able to swipe up over the content (not beside the content) to scroll the content up? I see above you mentioned "Page scrolling", which isn't what we are testing. Jroberson108 (talk) 13:06, 1 July 2025 (UTC)

Sandbox tables

Copied sandbox tables here below because this talk page has a working table of contents. Testcases page does not (on both iphone and Win 11 Pro PC. Plus I dislike bouncing around different pages on my iphone. I am not good at it, and I have limited time.

Short (no scroll)

Date	MoE
February 16–18	± 1.8%
February 3–6	± 1.8%

Tall (scroll)

Date	MoE
February 16–18	± 1.8%
February 3–6	± 1.8%
February 3–6	± 1.8%
February 3–6	± 1.8%
February 3–6	± 1.8%
February 3–6	± 1.8%
February 3–6	± 1.8%
February 3–6	± 1.8%
February 3–6	± 1.8%
February 3–6	± 1.8%
February 3–6	± 1.8%
February 3–6	± 1.8%
February 3–6	± 1.8%
February 3–6	± 1.8%
February 3–6	± 1.8%
February 3–6	± 1.8%
February 3–6	± 1.8%
February 3–6	± 1.8%
February 3–6	± 1.8%
February 3–6	± 1.8%
February 3–6	± 1.8%
February 3–6	± 1.8%
February 3–6	± 1.8%
February 3–6	± 1.8%
February 3–6	± 1.8%
February 16–18	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%
February 13–16	± 1.8%

Now I will try to look at it in my iphone and ipad. --Timeshifter (talk) 20:13, 2 July 2025 (UTC)

@Timeshifter: Normally this wouldn't work correctly as you would be mixing two competing styles.css (live and sandbox) on one page. The testcases page only uses the sandbox markup and sandbox styles.css. Since the only change currently is in the markup, copying it here will still work. Personally, I just use the link to jump to the section: Template:Sticky table start/testcases#Test premature wrapping. Jroberson108 (talk) 20:36, 2 July 2025 (UTC)

I added a TOC. Jroberson108 (talk) 20:43, 2 July 2025 (UTC)

I thought everything came from {{Sticky table end/sandbox}}? I don't understand the rest of what you said.

Is it possible to create a numbered sandbox (I have hundreds) that can use everything you mentioned? And would it be possible to include both the current template, and the sandbox template?

That would make it a lot easier for me. I really dislike that testcases page without the TOC (at least in Firefox). And I hate bouncing around between multiple pages. I have limited time currently. And I rarely use both my iphone or ipad. I have a house phone via Ooma ($6 a month) with many cordless handsets.

I keep all numbered sandboxes that are linked from discussions. So those discussions are not messed up by missing sandboxes.

Firefox on ipad shows the scrollbar if I drag on the table. No premature wrapping. Scrollbar is narrow and within the table. Just as in the iphone. It is on the far-right of the table next to the border, and does not cover any characters in the table.

Same for Firefox on iphone.

I really dislike that the scrollbar only shows up upon dragging. Tapping is not enough. It is not intuitive at all. How is one to know quickly (without reading table captions) which tables are scrollable or not when moving quickly down a page? One could easily think that all of the table was showing already. Is it possible to make the scrollbar visible without dragging?

On the iphone it is really difficult to drag on the table. Wikipedia keeps bouncing it out of place by popping up the "Add topic" banner. It would be easy to believe that the table is not scrollable. Ipad does not have this problem. Wikipedia does not pop up the "Add topic" banner on ipad.

I think this would be a good bug report for iphones using Wikipedia. I need to look at other browsers in the iphone to see if the same problem exists.

Chrome on iphone SE 2020. Same problem with "Add topic" banner popping up.

On both Firefox and Chrome on the iphone it seems to be a matter of chance whether dragging works. A thick scrollbar already in place without doing anything would help tremendously.

OK, I see now that one has to remember which direction to drag. So it is not a matter of chance. It is a matter of previous knowledge of how scrolling tables work. A thick scrollbar already in place would fix that problem too, because it would be more obvious which direction to scroll.

Safari on iphone does not show premature wrapping in the sandbox tables. Scrollbar only shows up when dragging the table. It covers the far-right of the table (like Firefox and Chrome). It is just to the right of the last character, but within the table border.

The problem with dragging is that one may be dragging the page down to view all of the page. But it is the wrong direction for dragging the scrollable table initially.

--Timeshifter (talk) 22:04, 2 July 2025 (UTC)

@Timeshifter: {{sticky table start}} includes "Template:Sticky table start/styles.css" while {{Sticky table start/sandbox}} includes "Template:Sticky table start/sandbox/styles.css", which is why you wouldn't mix the two on one page as the latter would have styles you would be testing. Normally on the testcases page, you would include both the live and sandbox versions for comparison, but because styles.css are used, you can only include sandbox.

The scroll bar not being intuitive is a common complaint about iPhone/iPad, but it's how Apple designed it to appear above the content to the right and only when scrolling. I'm sure people that regularly use those devices are use to it by now. I researched it and there is no reliable way to move the scroll bar to the gutter like on Windows nor is there a system setting to move it.

Wikipedia's "Add topic" banner should only exist on the talk page, so other pages like articles and testcases shouldn't have that problem. As I mentioned earlier, I added a TOC to the testcases page.

Good to know iPhone/iPad scrolling works. All browsers on those devices use WebKit, so they should function similarly. Sounds like this fixes the premature wrapping on Windows Firefox without introducing new issues in other browsers. Thanks for your help in testing. Jroberson108 (talk) 22:07, 2 July 2025 (UTC)

@Timeshifter: I did find this for iPad, but not sure if it still works or if iPhone has a similar setting. On iPad (and Mac), you can set scroll bars to be always visible by going to System Preferences (or Settings), then General, and choosing "Always" for the "Show scroll bars" setting. Jroberson108 (talk) 22:15, 2 July 2025 (UTC)

It seems that is no longer true for both iphone and ipad. Settings has search, and "scroll" does not pull up anything about scroll bars. Pulls up other scrolling stuff, but nothing about scroll bars. I see others complaining about this disappearance.

I did find this about forcing a scroll bar on webkit browsers:

• https://www.google.com/search?q=ipad+always+show+scrollbar

::-webkit-scrollbar {
  -webkit-appearance: none;
  width: 7px;
  height: 3px;
  -webkit-overflow-scrolling: auto;
}

About {{Sticky table start/sandbox}}. I see that you are still using Template:Sticky table start/styles.css

So if you wanted to use both current and sandbox tables on the same page (testcases page, personal numbered sandbox, etc.), and make changes in styles.css, then I assume you would have to create: Template:Sticky table start/sandbox/styles.css.

I assume for adding some kind of webkit code (like above) that would be necessary. I guess you could number those template sandboxes too, in order not to mess up past experiments.

This pulls up a lot of stuff:

• https://www.google.com/search?q=forcing+scrollbars+to+show+on+scrolling+tables

--Timeshifter (talk) 23:31, 2 July 2025 (UTC)

@Timeshifter: Wikipedia limits what styles can be added to styles.css. "::-webkit-scrollbar" is not allowed or any other vender prefixes such as "-webkit", plus that would most likely affect all scrollbars on iPhone/iPad including the one for the page scroll. As annoying as iPhone/iPad scrolling might be for some people, it works according to Apple's design.

{{Sticky table start/sandbox}} doesn't use "Template:Sticky table start/styles.css", but "Template:Sticky table start/sandbox/styles.css". When testing changes, you first do them in sandbox (Template:Sticky table start/sandbox and Template:Sticky table start/sandbox/styles.css) and test the changes on Template:Sticky table start/testcases without affecting the live/production version. You just add new testcases not remove or replace any that might be key to making sure everything is working correctly. If the tests are good, then you make the same changes to live. Jroberson108 (talk) 23:42, 2 July 2025 (UTC)

@Timeshifter: The changes are live. Jroberson108 (talk) 15:29, 3 July 2025 (UTC)

Mobile visual cue for scrollable area

@Timeshifter: As mentioned in the "Column width problems" discussion above, I cannot change the iOS/iPadOS scrollbar behavior. Scrollbar visibility in WebKit is controlled by the browser and operating system, not by web page scripts or styles. It is designed to only display when actively scrolled. Browsers on Android do the same except on some devices and browsers it also temporarily displays when the scrollable content is loaded or focused on as an initial indicator.

A common solution to this discoverability problem is to add a visual cue such as a shadow at the bottom of the scrollable area, which hides when you scroll to the bottom of the table so it doesn't hinder readability of the last row. Unfortunately with Wikipedia's limitations on templates, it can't be done with pure CSS. I did however create a companion user script so that JavaScript can implement it correctly. It only runs on Minerva, the default skin used on mobile devices. It works on Android Chrome and Firefox. You can test Safari on iOS/iPadOS if you want to see if it improves your experience.

You will have to add the following to your Special:MyPage/common.js page and be logged in to use it.

importScript('User:Jroberson108/Template:Sticky_table_start/ScrollCue.js');
importStylesheet('User:Jroberson108/Template:Sticky_table_start/ScrollCue.css');

Jroberson108 (talk) 15:29, 3 July 2025 (UTC)

@Jroberson108:

I added it.

See: User:Timeshifter/common.js

That is an improvement on my iphone in Firefox. Thanks. I see nothing on Firefox in ipad. Can test here:

Template:Sticky table start/doc

Need something else. I was thinking of some kind of small image or icon that could go in the front of the table caption. Or elsewhere. Such as arrowheads at the bottom of the table.

It would be put there by the template.

Something representative of scrolling. With a tooltip in the caption icon saying "Scrollable table if full table is not visible in your screen".

Since the table caption disappears upon scrolling, so would the icon, and so it would not take up valuable space.

I see some mouse movement indicator illustrations that might work in google image results.

https://images.google.com

Example searches:

scrolling symbols for tables.

symbols for vertically scrollable tables on mobile

These are royalty free:

https://www.istockphoto.com/illustrations/scroll-down

Simple stuff like those images are not copyrightable anyway. See:

c:Template:PD-ineligible

Thin arrowheads on a narrow partial blank row at the bottom of the table. That partial row would disappear upon beginning to drag the table up to see more of it. Opposite of keyboard arrowhead:

^^^^^^^^^^^

Unicode characters for various down arrowhead symbols.

https://www.google.com/search?q=Unicode+characters+for+various+down+arrowhead+symbols

c:Category:SVG down arrow icons

White arrowhead with thick black outline would work in both light and dark mode on Wikipedia. Here is a non-copyrightable example (without the watermark):

https://www.dreamstime.com/downward-pointing-triangle-vector-outline-icon-design-generative-ai-represents-down-collapse-lower-priority-direction-image381446312

I notice on my ipad on the doc page that many of the tables show partial rows at the bottom of the table. That is a clear indicator of a scrollable table.

I don't see that as often on my PC monitor.

Maybe that could be forced somehow. Some way to block integer numbers of rows showing.

--Timeshifter (talk) 23:59, 3 July 2025 (UTC)

@Timeshifter: Is your iPad using Minerva and are you logged in?

Remember that not all tables have a caption. A lot of what you are asking for is dynamic requiring JavaScript, which templates don't allow, so "It would be put there by the template." is not possible in most cases. This template cannot add a tooltip caption. It cannot add an extra table row to the bottom. It cannot make something disappear upon scrolling. CSS can only style existing elements. The template only places some markup around the table and styles that markup and the things contained in it. That's the whole reason I had to do a user script, which has its own caveats.

PC browsers have persistent scroll bars, so not sure why you feel that is not enough. Jroberson108 (talk) 00:18, 4 July 2025 (UTC)

You are right. I was just wondering why the doc tables on my PC monitor were different in not showing as many partial rows as on the ipad.

Maybe someday Mediawiki will do fully sticky tables, and be able to use Javascript. A couple of these Unicode characters could be put side-by-side at the bottom of each column whenever the table was taller than the screen:

U+2304 is Unicode for this downward arrow: ⌄

See underlying wikitext to see how to display the arrowhead.

I am logged in on the ipad. I was using Firefox. I see that MinervaNeue is a choice in preferences. I don't know if I have ever selected it. Wouldn't that also put Minerva on my PC view too? I probably wouldn't want that?

How were you able to get the enable/disable buttons on the sticky template without Javascript?

Maybe put "Scrollable table if needed" in the same spot just above the table. Height setting for table wouldn't include it since it is not part of the table.

OK. I see I can select "mobile view" at the bottom of Wikipedia pages on the ipad. And it does show the shaded partial row at the bottom of the fully sticky tables.

Unfortunately, Minerva doesn't have the floating table of contents I like in Vector 2022. --Timeshifter (talk) 01:07, 4 July 2025 (UTC)

@Timeshifter: The reason templates don't allow JavaScript is for security reasons. The enable/disable buttons used JavaScript from mw-collapsible and only required including the class, which I hackishly modified the projects styling to make it not hide the entire content. Sortable also uses JavaScript, but similarly we only have to include the class to use it, which {{sort under}} modifies its styling. Both have JavaScript added through the backend, not through templates.

There is no way to tell with pure CSS which tables are actually scrollable. It depends on the size of the screen, table, font, etc., which JavaScript can do.

Sounds like your iPad is large enough where it doesn't default to Minerva. Just curious, but do the scroll bars always show on iPad the same way it does on PC browsers using the default skin? If you change the skin to Minerva in preferences, then it would change your PC too. The user script I created is only to help a little with discoverability when the scroll bar is not initially present as an indicator, which sounds like it is only on iPhones. Unless someone includes it in their user scripts and is logged in on their phone (Minerva), it doesn't get used. Jroberson108 (talk) 01:49, 4 July 2025 (UTC)

On ipad in both Chrome and Firefox I do not see the vertical scroll bars on Wikipedia fully-sticky tables. In both desktop and mobile view. Even when I am scrolling the table up and down.

Hacking is good! If it allows you to make scrollable tables noticeable on iphones and ipads.

Iphone is default Minerva regardless of logged in or not. But, unlike the ipad, I can see a narrow scroll bar show up once I start to drag the table up or down. But not before I drag.

Same is true if I click the "desktop" link at the bottom of the iphone Wikipedia page. I can see a narrow scroll bar show up once I start to drag the table up or down. But not before I drag. I have that floating table of contents so it must be Vector 2022. --Timeshifter (talk) 02:32, 4 July 2025 (UTC)

@Timeshifter: On iPad, if you are scrolling over the content and no scroll bar shows, then it sounds like a browser/iPadOS rendering issue or quirk. The behavior of scrollbars on iPadOS is controlled by the system and should be consistent across all apps and browsers. It should work the same as it does on iPhone: appear while scrolling, and disappear otherwise. What OS version does you iPad have? Jroberson108 (talk) 03:21, 4 July 2025 (UTC)

@Timeshifter: I modified the user code to also apply to WebKit. Minerva is still included. This way iPadOS browsers and macOS Safari are also included. That being said, I shortened the import names to something broader and deleted the old pages. See the import code above to update your common.js page. Can you make sure the cue still shows on iPhone? For iPad, you shouldn't need to switch to Minerva for the cue to display. Jroberson108 (talk) 04:54, 4 July 2025 (UTC)

I have latest standard ipad 2020 OS: iPadOS 18.5

I updated the javascript.

On ipad 2020 when signed in to Wikipedia. Mobile view (Minerva): The graying at bottom of fully-sticky tables (when full table is not visible outright on screen) is seen in all browsers tested: Safari, Firefox, Chrome, Edge. Scrollbar not visible ever on fully-sticky tables in all browsers tested: Safari, Firefox, Chrome, Edge. Dragging table up or down makes no difference.

On ipad 2020 when signed in to Wikipedia. Desktop view (Vector 2022 in my preferences): Results are exactly the same as mobile view for all the browsers. Concerning scrollbar and graying.

Also need to test iphone browsers.

--Timeshifter (talk) 06:58, 4 July 2025 (UTC)

@Timeshifter: In summary, the new scroll cue works on iPad 2020 (iPadOS 18.5) in Minerva and Vector 2022 skins. The scroll bar did not display when actively scrolling. I researched some and found the following:

1. Scrollbar invisible when device in dark mode and the page uses a light theme.Bug 213394[3][4]
2. Light background colors can make scroll bar appear invisible.[5] (Note, I cannot change the scrollbar color for iOS/iPadOS.[6])
3. Connected devices (keyboard/mouse) may affect the scroll bar.[7]
4. Shrinking window or zooming in and out might trigger the scrollbar to appear.[8]

For #1, if device uses dark mode, test by changing device and Wikipedia light/dark modes. For #2, test with a table that has a white background since the wikitable background-color could be similar to the scroll bar color that is over the table's edge. For #3, disconnect devices and maybe restart. For #4, testing is already explained. Jroberson108 (talk) 14:56, 4 July 2025 (UTC)

@Timeshifter: The WebKit detection code I had was returning true for Windows browsers too, so I had to make it more specific. I've tested and the shadow only shows on Windows when Minerva skin is used and on Android that uses Minerva by default. Jroberson108 (talk) 14:34, 7 July 2025 (UTC)

Sorry. I have been busy. Hope to get around to more Wikipedia stuff. We need a pool of iphone and ipad users to test out stuff. Some kind of way to ping them too. A list of participants on some talk page section dedicated to this purpose only. Participants would all subscribe to that talk page section. Then someone in need would sign the section after leaving a link to the page, talk page, sandbox, etc. needing iphone, Mac, and ipad help. That would ping everybody. --Timeshifter (talk) 23:35, 8 July 2025 (UTC)

Iphone SE 2020: I was logged in to Wikipedia. In both mobile and desktop view: The gray area at the bottom of fully sticky tables shows up in these 4 browsers: Safari, Firefox, Chrome, Edge.

The scroll bar shows up too. But only after dragging within the table. Tapping in the table is not enough.

More later hopefully. --Timeshifter (talk) 11:03, 12 July 2025 (UTC)

Ipad 2020. Logged in: Safari in both mobile and desktop view: Scrollbar not visible in light mode. It is visible in dark mode, but only when dragging the table. Logged out: Same is true.

Ipad 2020. Logged in: Gray cueing: In Safari it is visible in both mobile and desktop views. And in both light and dark modes. --Timeshifter (talk) 06:56, 14 July 2025 (UTC)

@Timeshifter: Thanks for testing. Sounds like the shadow cue works correctly now.

The only issue you found was scrollbar on iPad light mode having a similar color to the table's background color making it look invisible (visible in dark mode). Since it also occurs logged out, then it is unrelated to the cue or any Wikipedia settings.

You could test that scenario on a table with a white background color to be sure it looks invisible and isn't missing. If it's still missing, then it may be the device and you may have to explore the other three tests I mentioned above. Jroberson108 (talk) 12:20, 14 July 2025 (UTC)