Template talk:Sticky table start

Archives: no archives yet (create)

This page has archives. Sections older than 180 days may be automatically archived by when more than 3 sections are present.

Tests of new template

Note: See previous discussion: Template talk:Sticky header#Template:Sticky table start and Template:Sticky table end.

Thanks Jroberson108. Here are some tests:

User:Timeshifter/Sandbox264 - Single top row. Covid CSS.
User:Timeshifter/Sandbox265 - Single top row. {{sticky table start}}
User:Timeshifter/Sandbox266 - Multi rows in header. {{sticky table start}}

What I have noticed in my iphone SE 2020. Sticky headers work fine on the single row in Safari and Chrome. Except that the right border of the left-sticky column disappears upon use.

Sticky headers work strangely on the multi-row top headers. In both Safari and Chrome. Same problem also with right border of the left sticky column.

Looks like the colspans are causing problems in the multi-row top headers? --Timeshifter (talk) 10:52, 28 July 2024 (UTC)[reply]

For the rowspan problem on 266 where left sticky is applied to some of the next column, use the "sticky-table-unsticky" class on those two cells: "Number" and "Total".

For the border, I'll have to take a closer look at how they differ from the covid CSS ones. Jroberson108 (talk) 14:57, 28 July 2024 (UTC)[reply]

Done. Thanks. 266 is working great now. I highlighted the wikitext. --Timeshifter (talk) 18:13, 28 July 2024 (UTC)[reply]

The borders fix was reversed on {{sticky header}} from what the covid CSS had to fix the borders for {{static row numbers}}. Reversing them back and applying the remaining styles will fix the issue, but one of the top borders will be missing for the {{static row numbers}} column, specifically the one that separates the header/sorttop rows from the rest of the data that follows. You can see the difference on the testcases pages in the following sections ~~and the three sections that follow them~~:

Jroberson108 (talk) 19:56, 28 July 2024 (UTC)[reply]

Jroberson108 and HouseBlaster. Moved thread here.

I think the right-side border on the left-sticky column is more important. --Timeshifter (talk) 08:29, 29 July 2024 (UTC)[reply]

@Timeshifter: I can agree that the right/bottom borders are more important to keep visible when sticky. The changes are live now. There are no other sandboxed styles. Feel free to update the doc. I only added two quick examples, but might need more.

The {{sticky header}} issue should be moved to that template's talk in a new section. Jroberson108 (talk) 14:51, 29 July 2024 (UTC)[reply]

Done. See Template talk:Sticky header. --Timeshifter (talk) 10:29, 30 July 2024 (UTC)[reply]

Expand/Collapse toggle button

@Timeshifter and HouseBlaster: See Template:Sticky table start/testcases. I added a way to show (expand w/o sticky) or hide (collapse w/ sticky) the table, but not fully hide the content so it stays accessible. This is similar to the covid CSS expand/collapse behavior. This provides a way to disable the sticky features for cases where on mobile the sticky portions are too wide or tall and covers most or all of the data making the data unreadable (accessibility issue). What do you think? I haven't fully tested it. Jroberson108 (talk) 20:51, 29 July 2024 (UTC)[reply]

LGTM on my Mac in Firefox, Chrome, and Safari. Thank you for your work! House Blaster (talk · he/they) 23:33, 29 July 2024 (UTC)[reply]

Template:Sticky table start/testcases.

About the expand/collapse toggle button. In its current location inside the scroll window it is further limiting the number of data rows visible in my iphone browsers. I only see one data row in landscape view in my iphone SE 2020.

I suggest putting the toggle button above the scroll window, and not in the scroll window. The button is above and outside the scroll window in the covid CSS tables here:

COVID-19 pandemic by country and territory.

--Timeshifter (talk) 13:42, 30 July 2024 (UTC)[reply]

It isn't sticky, so it will scroll out of view. It can be moved above, but will add more height to the total page. Keep in mind that the covid CSS is a different implementation that has less testing and features. Its usage will most likely be replaced by this template before deletion. Jroberson108 (talk) 17:15, 30 July 2024 (UTC)[reply]

It has been moved outside the scroll div. Jroberson108 (talk) 18:47, 30 July 2024 (UTC)[reply]

Thanks. That definitely helped {{sticky table start/sandbox}}. --Timeshifter (talk) 20:37, 30 July 2024 (UTC)[reply]

New template fixes page width problem

One really good thing about this template is that it fixes the problem of wide tables messing up page widths in Chrome in my iphone SE 2020.

For example see this version of COVID-19 pandemic by country and territory.

Specifically the wide table in "Cases and deaths by region" section. In that page version it is using {{sticky header}}.

I will change it to {{sticky table start}}. I did, and it fixed the page width problem. --Timeshifter (talk) 12:55, 30 July 2024 (UTC)[reply]

Template:Screen reader-only

In the previous talk section I discussed a wide table. I noticed that only one data row was showing in Chrome on my iphone in landscape view.

Due to the multi-line header, and due to the long wrapping caption inside the scroll window. Also, due to the wrapping within rows.

I copied the caption and put it outside and above the scroll window. I then added Template:Screen reader-only to the caption inside the table.

Now I see 2 data rows. They are taller rows due to some wrapping within in the rows. When I scroll down to narrow rows, I see 3 data rows in landscape view.

It would be nice if the sorting arrows could disappear upon scrolling.

All this stuff adds up: toggle location, caption location, sorting arrows, and number of header lines. --Timeshifter (talk) 13:11, 30 July 2024 (UTC)[reply]

Which table? The collapsible button and caption aren't sticky, so they will scroll out of view. As I recall, keeping the caption in the table's caption element is probably needed for screen readers unless aria tags are added. You would need JavaScript to hide the sort arrows upon a scroll event in the div when not scrolled at the top. Not possible with these templates. Jroberson108 (talk) 16:50, 30 July 2024 (UTC)[reply]

The table in the section titled "Cases and deaths by region":

COVID-19 pandemic by country and territory#Cases and deaths by region

The caption remains in the table's caption element when using Template:Screen reader-only. But it is not seen by sighted readers, and it does not get in the way. The caption is duplicated above the table for sighted readers. This particular table does not have a collapsible button.

I will have to show the various options on a sandbox page, because it is hard to explain without seeing the differences in a cell phone. --Timeshifter (talk) 19:46, 30 July 2024 (UTC)[reply]

So sighted see "caption" above table. Screen reader has it above and in the table, basically read twice. I can't see many editors going the extra mile to do this. Anyways, it isn't anything that can be done through this template. Jroberson108 (talk) 20:01, 30 July 2024 (UTC)[reply]

Template:Screen reader-only is on 46,000 pages. I didn't know it existed, or I had forgotten. I intend to use it often. Solves several problems. See:

User:Timeshifter/Sandbox268. In landscape view on my iphone it has 3 lines in the table header.

Look at it in a cell phone. In my iphone SE 2020, {{Screen reader-only}} increases the number of data rows that are visible in landscape view. I use larger fonts in my cell phone. So it matters even more. Larger fonts means less data rows are visible.

When I first look (before touching the table) I see one data row without it. I see 2 data rows at first when I use it.

It is important that people know this, so that they are more encouraged to use {{sticky table start}}. --Timeshifter (talk) 20:34, 30 July 2024 (UTC)[reply]

FYI, tall headers are mentioned on both templates (Template:Sticky header#Usage and Template:Sticky table start#Usage): "Avoid making excessively tall header rows sticky that might block too much data on short screens (ex. mobile landscape)." Since sticky headers can't be disabled, really tall ones could make the data unreadable regardless of scrolling, which is why the "expand" is there to disable sticky. Caption isn't sticky, so it will scroll out of the way whether it is in or above the scroll div. I don't have any issues with the caption being in the table on my Android landscape view. If I want to see more rows, then I flip to portrait view, which is a normal practice. Jroberson108 (talk) 21:03, 30 July 2024 (UTC)[reply]

Putting the caption outside the table also solves the problem HouseBlaster discussed. The caption wraps to the screen width.

The expand/collapse toggle is useful. But then one is back to a table that can cause page width problems if the table is wide. And an expanded wide table can be very difficult to follow if the info one wants is in the columns farther to the right. It is hard to connect the location to the correct data in those columns.

So we need to tell people how to shorten column headers. One way is to put more info in the captions. I do that often. Like putting "rates" instead of "Rates per 100,000 people" in the column head. I put "rates per 100,000 people" in the caption, or a note above the caption.

It takes a few experiences with the scroll tables to learn how to use them. And it is easier if more data rows are visible.

I need to look at a wide scroll table in landscape view sometimes. I may alternate between portrait and landscape to get a more complete picture.

Your Android phone is probably bigger than my iphone, and you probably use a smaller font than me.

So I am pointing out stuff that makes scroll tables accessible to more people. --Timeshifter (talk) 22:56, 30 July 2024 (UTC)[reply]

I already know about moving some header info to the caption to reduce headers. You asked me to look at the page, so I did and gave my thoughts. I read the table caption the same way I read the table headers and data, by scrolling horizontally if it doesn't fit on the screen. I don't find it to be an issue for me since on phones you naturally scroll horizontally to read something that goes beyond the viewport the same way you vertically scroll when the content is longer. Once you scroll, the same number of data rows will be visible regardless of where the caption is placed since, again, the caption isn't sticky. I don't have anything more to add to this discussion since it isn't something that can be done through this template. Editors have to choose to manually change the caption, which you are welcome to do to your tables. If I find a way to wrap the caption using CSS, then I'll add it, but I found nothing thus far. BTW, I use the default font size, which I would assume most use. Jroberson108 (talk) 00:18, 31 July 2024 (UTC)[reply]

I mentioned at Template talk:Sticky header#Discussion that the CSS wasn't supported by the template styles. You can however add it inline to the table caption like so:

|+ style="max-inline-size: 85vw; overflow-wrap: break-word;" | COVID-19 cases and deaths by region, in absolute figures and rates per million inhabitants as of 25 December 2022

Though, I haven't tested it across all skins to make sure it works and "85vw" is low enough. Jroberson108 (talk) 00:28, 31 July 2024 (UTC)[reply]

You wrote that the inline CSS for the caption didn't work with sidebars. I remember confirming that myself by alternating between Vector 2010 and 2022. We didn't discuss it further. I thought it was a settled discussion. But I am confirming it now. I assume it is true also for people alternating between the different tables of content (sidebar versus floating icon TOC). I also noticed other problems if I am remembering correctly.

Thanks for putting the expand/collapse functionality in the template. I personally find the expand/collapse button most useful on my desktop monitor. It allows me to more rapidly scroll up and down a table without fiddling with scroll bars. So I can rapidly go down a page with many scroll tables until I find one I want to check out in more detail in expanded form. I think it will also alleviate a main objection some people may have with the new template. That objection being that scroll tables are different. :)

I don't find the expand/collapse ability very useful to me on my iphone unless the table width fits in landscape view. Then it is useful since I don't have to fiddle with scroll bars. I can just drag the page up and down.

I hope to add some notes to the template doc eventually to point out some of the accessibility problems and solutions. --Timeshifter (talk) 10:20, 31 July 2024 (UTC)[reply]

Ah yeah, I forgot about the inline CSS not working with sidebars. Jroberson108 (talk) 13:47, 31 July 2024 (UTC)[reply]

Some articles with the new template

All the sticky tables also use Template:Screen reader-only. It makes a big difference in cell phones. Can quickly scroll down a page in portrait view, while being able to read the table captions. Since they wrap due to being outside the table. --Timeshifter (talk) 12:09, 2 August 2024 (UTC)[reply]

For the first link, the small tables in these sections fully fit on the screen, at least mine, and probably don't need to use this template:

By territory and percentage female
Juvenile detention

This table needs to use the "sticky-table-unsticky" class on two cells:

Male and female incarceration and correctional supervision

For all tables on both links with a left-sticky column, I recommend moving the flags to a separate column to reduce the amount of sticky data so more underlying data is visible when horizontally scrolling. Jroberson108 (talk) 12:53, 2 August 2024 (UTC)[reply]

Thanks. I missed those unsticky classes. I remembered elsewhere though.

The small tables don't fit fully on my cell phone screen.

Is it possible for the template to remove the expand toggle when a table fully fits on the screen?

I don't know how to put the flags in a separate column. Please point me where I need to go. --Timeshifter (talk) 18:10, 2 August 2024 (UTC)[reply]

I can't think of a pure CSS way to hide the expand button based on the table's content width being narrower than the main content area. I would think JavaScript is needed.

There's a separate column of flags at Template:2020 monthly cumulative COVID-19 death totals by country. Jroberson108 (talk) 18:31, 2 August 2024 (UTC)[reply]

OK, thanks. Here is the diff where the flags were put in a separate column. It looks like something I can do with find-and-replace with the {{flagg}} template. I need to figure it out more, and put the procedure on one of the Help:Table pages. --Timeshifter (talk) 00:05, 3 August 2024 (UTC)[reply]

Can the expand/collapse button be made invisible?

Can the "expand/collapse" button be suppressed/made invisible so it does not show in smaller tables with sticky rows, for example, WTA 1000 Series singles records and statistics#1000 (since 2024) and WTA 1000 Series doubles records and statistics#1000 (since 2024)? Qwerty284651 (talk) 20:04, 4 August 2024 (UTC)[reply]

@Qwerty284651: That can be tricky. Although it may be considered small on desktop, it may be large on mobile. There isn't a way for the template to know the size of the table as compared to the viewport in order to guess if scroll is available. I believe JavaScript might accomplish this automatically, but it isn't allowed. The purpose of the toggle, in my view, is mostly to circumvent problems on smaller devices in the case where the sticky portion is overly large and covers too much or all of the visible underlying scrollable data. All I can think to do with pure CSS is to only show the toggle when the viewport is smaller so it still works on all skins. Jroberson108 (talk) 20:23, 4 August 2024 (UTC)[reply]

I meant making it invisible manually by using a custom param, for example |expand_button=no or similar if possible, of course. Qwerty284651 (talk) 22:29, 4 August 2024 (UTC)[reply]

@Qwerty284651: Adding a template parameter would be possible, but it can be forgotten about if used on a small table that grows over time. For a more automated solution, I added some CSS to only show the toggle button on smaller screens. Jroberson108 (talk) 23:00, 4 August 2024 (UTC)[reply]

Thank you for the alternative. Qwerty284651 (talk) 23:03, 4 August 2024 (UTC)[reply]

Separate column of flags

Copied from a previous thread:

There's a separate column of flags at Template:2020 monthly cumulative COVID-19 death totals by country. Jroberson108 (talk) 18:31, 2 August 2024 (UTC)[reply]

OK, thanks. Here is the diff where the flags were put in a separate column. It looks like something I can do with find-and-replace with the {{flagg}} template. I need to figure it out more, and put the procedure on one of the Help:Table pages. --Timeshifter (talk) 00:05, 3 August 2024 (UTC)[reply]

I finally got around to comparing the country columns in my iphone SE 2020:

Once you start horizontally scrolling the country columns have the same exact width. They can't get any less wide than the widest word. Which in this case is Liechtenstein. Turkmenistan is another wide word.

So there is no advantage in using a separate flag column in that respect after horizontal scrolling occurs.

And before one scrolls, the flag column actually takes up space on the screen, and makes for less available width for data columns. Just like the static row numbers column. Fortunately, both those columns disappear upon scrolling horizontally.

The only small advantage of having a flag column is that fewer country names need to wrap to 2 lines. Some multi-word countries for example. And some of the longer country names wrap to 2 lines with the flag on one line, and the country name on the other line.

For me personally with my small-screen iphone SE 2020 (and larger text) I prefer having more initial data column space in portrait view. By not having a separate flag column. --Timeshifter (talk) 16:13, 6 August 2024 (UTC)[reply]

Good to know that the two versions have the same width once sticky and wrapped. Yeah, makes since having all in one cell would be taller in some cells. Looks the same on my Android too. Did you want me to change the covid ones to one column? As I recall, the original purpose was to reduce the amount of sticky data, so excluding flag. Jroberson108 (talk) 16:34, 6 August 2024 (UTC)[reply]

I leave that up to you. Either way. Personally, I would like to remove all flags from tables. It's just more work, and serves no purpose. I would consider a Village Pump proposal to ban them from tables.

Flags should only be allowed if they are in the column farthest to the right. That might get some more interest at a Village Pump discussion. :)

--Timeshifter (talk) 22:22, 6 August 2024 (UTC)[reply]

I'll leave it alone then. I agree, flag images are only for aesthetics when next to the name of a country/state/etc in a table that isn't about flags. Jroberson108 (talk) 22:51, 6 August 2024 (UTC)[reply]

Template shortcut proposals

I propose to make template shortcuts for {{Sticky table start}} -> Template:sts and {{sticky table end}} -> Template:ste (not sure if the "template:" namespace is mandatory for template shortcuts' name).

I am open for suggestions for other shortcuts. Qwerty284651 (talk) 10:39, 12 August 2024 (UTC)[reply]

"sts" links to {{skip to section}}. Jroberson108 (talk) 15:22, 12 August 2024 (UTC)[reply]

I don't know if an acronym shortcut would help the template to be used more or not. It would confuse editors who come across it. On the other hand, editors who figure it out will probably use the template more. I am leaning towards creating some shortcuts. Some templates have more than one shortcut. So I guess the more the better, because more editors will use the template.

Template:Sticky, unfortunately, is already taken. Template:Fixed is taken. Template:Start is taken. Template:ST is not taken. Template:st is taken. Running out of the first shortcuts that come to mind.

Imagine if all the common table templates on top of a table were all acronyms. It would be nice if a bot came around now and then, and spelled them out later. Then we would have speed, and easier comprehension. --Timeshifter (talk) 17:31, 12 August 2024 (UTC)[reply]

@Qwerty284651: Did you have a reason for requesting it? Personally, I don't think it would "increase" usage since you wouldn't use this template unless needed, which would be for tall and/or wide tables. If you aren't familiar with the acronym, it might become harder to find this template. Googling "wikipedia sticky table start" w/o quotes, I can find this template. Googling "wikipedia template sts" w/o quotes with an extra "template" to narrow it down, I cannot find the "skip to section" template. If a bot did spell them out, then that would be nice, but that would add more overhead. When editing a page, there is a list of transclusions at the bottom, but that is a hassle to read through and may not be apparent to most editors. Jroberson108 (talk) 20:58, 12 August 2024 (UTC)[reply]

It is usually more for convenience/ease of access to instead of type out the whole thing one can use abbreviations like {{cot}} and {{cob}} or {{hat}} and {{hab}} template wrappers similar to sticky table- start and -end. And, no, the goal is not about increasing usage but moreso ease of access.

Googling "wikipedia sticky table start" w/o quotes, I can find this template. Googling "wikipedia template sts" w/o quotes with an extra "template" to narrow it down, I cannot find the "skip to section" template.. One can always find a template by opening it in source and adding "template:" in the wiki's search bar, something that admittedly not many newcomer editors are aware off. And not all transclusions are of templates but I digress. Qwerty284651 (talk) 23:22, 12 August 2024 (UTC)[reply]

I remember one editor who created a template, and an acronym shortcut for it, and used it often. So it does increase usage. For that template I always used the full name of the template. I can't remember the template now. There are many templates that use acronym shortcuts that are often used. Over time people see both the shortcuts and the acronyms. I think it is a net benefit.

All country and US state tables are taller than the screen height. So I think this template will eventually be used often. It makes navigating pages much faster. Especially for getting to parts of the page other than the tables. Or navigating pages with multiple tables. One can scan a page quickly without having to guess what is on the page from a poorly written table of contents. Or quickly scanning a long page with multiple tables, and many sections. Without having to use the same table of contents that does not have an "expand all" button. :)

I don't know if a bot can be created that automatically periodically (once a week or month) specifically looks for a shortcut. One that is started, and no longer needs help from a human to continue on. I believe there are various bots on Wikipedia that function totally automatically, except for maybe an emergency stop button. So a bot could maybe be set to look at the results of a "what links here" link to the template shortcut, and then go and replace the shortcuts. Might have to ask at WP:VPT to see if this is possible.

But I don't think the bot has to be created to justify creating shortcuts. As I said, I think shortcuts are a net benefit. --Timeshifter (talk) 01:29, 13 August 2024 (UTC)[reply]

I'm willing to bet that if that one editor couldn't create the acronym, they would have still used the template as many times purely out of necessity, not because of how short the transclusion name was. Just saying that it isn't easy to prove increased usage without actual test cases and analytics, and how substantial the increase is. I agree that it might make it more convenient to transclude if the acronym is easy to remember like "hat". Create it if you want. Jroberson108 (talk) 02:27, 13 August 2024 (UTC)[reply]

There is also the amount of time to type out multi-word templates versus an acronym. That alone would account for more usage of the template. I myself have a text file (tables.txt) that is always open (along with many other text files) in NoteTab Light. It has the templates and class names handy for copying into tables.

I just created the redirect: {{ste}}.

I might use that. It's faster to type in 3 characters (and brackets) than finding its full name in the text file, or at the top of the table, and copying and pasting it to the bottom of the table. --Timeshifter (talk) 03:56, 13 August 2024 (UTC)[reply]

So a bot could maybe be set to look at the results of a "what links here" link to the template shortcut, and then go and replace the shortcuts. why would the bot "replace" shortcuts?

But I don't think the bot has to be created to justify creating shortcuts. Not all templates need shortcuts. For example, main, for, expand, clarify don't need shc. Even 2-word ones like see also don't. Polysyllabic and 2+ word templates do: {{aan}}.

{{Ste}} is missing an already taken {{sts}} as a counterpart. Cot/cob, hat/hab use "top" and "bottom" nomenclature, for a lack of a better term, to specify the placement of the template pair. I feel sticky table start and -end should, if we follow the above logic, be renamed to sticky table top and sticky table bottom, respectively. Shortcuts would be stickyt (sticky top) and stickyb (sticky bottom) or stit/stib as shorter alternatives or both. Qwerty284651 (talk) 23:38, 13 August 2024 (UTC)[reply]

Jroberson108. Have you seen this last reply of Qwerty284651? I personally won't be using shortcuts with this template. But if they help others use it, I have nothing against changing the template name. Then we could use: {{stt}} and {{stb}} and so on. Oops, those are taken. So I guess that leaves the other ones: stickyt (sticky top) and stickyb (sticky bottom) or stit/stib

Qwerty284651. I think full template names help editors in figuring out what is happening with a table. So having a bot go around now and then, and replace those using acronyms is helpful. For example, here is a row of table templates I have used often:

I will be substituting {{sticky table start}} for {{sticky header}}.

Imagine someone seeing this, or something similar, and trying to figure out what is going on:

{{srn}}{{mwd}}{{sts}}{{su}}{{ta}} --Timeshifter (talk) 21:47, 14 August 2024 (UTC)[reply]

Qwerty284651. {{stickys}} (sticky start) and {{stickye}} (sticky end) or {{stis}}/{{stie}}. Those could be used now with the existing template names. --Timeshifter (talk) 22:14, 14 August 2024 (UTC)[reply]

I won't be using them either since I prefer clarity and agree that the longer version helps to both figure out which templates are used and more easily find them. I don't know of any bot that replaces transclusion redirects. I don't really see a big benefit to having shorter versions on a new template that has a niche usage on tall and/or wide tables. There are other sticky templates: {{sticky header}}, {{import style}} w/ "sticky" parameter, and {{sticky}} (draft?). The obsolete covid sticky CSS. Although not transcluded, the sticky table headers gadget. If you think having stickyt/stickyb or stickys/stickye is beneficial and won't cause confusion, feel free to create them. Jroberson108 (talk) 22:30, 14 August 2024 (UTC)[reply]

I created {{sticky top}} and {{sticky bottom}} as template shortcuts for {{sticky table start}} and {{sticky table end}}, respectively, as a compromise to have shortcuts with logical full names instead of abbreviated unprintworthy ones. Qwerty284651 (talk) 21:30, 21 August 2024 (UTC)[reply]

I like {{sticky top}} and {{sticky bottom}}. They are clear, and easy to remember. I may be using them, and these too: {{sticky start}} and {{sticky end}}. Depending on which ones I remember first. --Timeshifter (talk) 13:07, 22 August 2024 (UTC)[reply]

Documentation page update

The div classes: sticky-table-collapsible and sticky-table-scroll listed in Template:Sticky table start/styles.css should be added to the doc page. Qwerty284651 (talk) 10:48, 12 August 2024 (UTC)[reply]

Why should they be listed? They are added through the start template and aren't something most editors need to worry about. Adding them to this doc has the potential of complicating and confusing things for editors beyond the classes they should be aware of. Jroberson108 (talk) 15:34, 12 August 2024 (UTC)[reply]

If editors can't do anything with them, then why explain them? It would be like trying to explain all the coding in templates, modules, etc.. --Timeshifter (talk) 17:35, 12 August 2024 (UTC)[reply]

Aha, I see. I thought the div classes are extra, optional parameters one can use to modify the template not a built-in feature/code of the template that is executed when the template is used. Good to know. Qwerty284651 (talk) 23:06, 12 August 2024 (UTC)[reply]

Expanded table is not sticky. Also, background colors removed

See this version of Wikipedia:Reliable sources/Perennial sources#Sources

After one clicks a letter in the horizontal TOC, the table expands. The expanded table is no longer sticky.

And the background colors have been removed from both the non-expanded table, and the expanded table.

Would it be possible for the template to detect the use of the horizontal TOC, and collapse the table? Or add a collapse button? Or convert the table back to a sticky table. At least a top sticky table.

Or maybe go back to having the expand and collapse buttons on all tables? Maybe with a note that "The table may already be expanded". Or "The table may already be expanded on some screens". If not a note, then a tooltip saying that.

I went ahead and added the old template {{sticky header}} to the table. It does not seem to be removing the background colors as {{sticky table start}} did.

See {{sticky header}} in this version of the table. --Timeshifter (talk) 04:51, 13 August 2024 (UTC)[reply]

The "mw-collapsed" class is being removed for some reason when a {{Compact ToC}} link is clicked that links inside the table ("Legend" works). I'll have to take a closer look.

The background-color wasn't removed, just set to "inherit" to fix a transparency issue when the sticky element has content scrolling behind it. Setting the background-color inline should override it. That table uses a style sheet and sets the color through a class. {{Sticky header}} doesn't offer a left-sticky column like this one, so its transparency fix is a little different. I'll have to take a closer look to see if it can be fixed along with transparency.

A lot of the detect and modify you are asking for might be doable with JavaScript, but not CSS. Jroberson108 (talk) 05:39, 13 August 2024 (UTC)[reply]

For the background color, I suggest appending "... !important" to the five colors at Wikipedia:Reliable sources/Perennial sources/styles.css so they aren't overridden by "inherit". Example: background-color: #dfd; changes to background-color: #dfd !important;. I don't see any other way to fix sticky transparency issues on other tables without setting the background-color to inherit, which only affects non-header cells. Using "!important" should be avoided, but is needed sometimes. Looks like those color styles are only used on four pages: search. If you aren't going to use this template on those pages, then no changes needed. Jroberson108 (talk) 17:03, 13 August 2024 (UTC)[reply]

For the TOC link, if the link goes to something inside of a collapsed area (table, paragraph, etc.), it expands it so it is visible. Otherwise, it wouldn't make sense to link to hidden content. Collapsible has always been used to completely show or hide content, not to partially "hide" (not hidden, just scrollable) content like what this template does. This template uses the collapsed state for enabled (scrollable and sticky) and the expanded state for disabled (not scrollable or sticky).

Not sure if some JavaScript is doing this since I didn't look into something I can't change? Always showing the toggle isn't a fix since the user will have to collapse/enable the features every time a link is clicked. The only fix I can think of is to reverse this (collapsed = disabled, expanded = enabled), if possible. The aria-expanded attribute will be reversed for a screen reader though. Since the table isn't completely hidden, the screen reader can read the content in either state. Jroberson108 (talk) 17:46, 13 August 2024 (UTC)[reply]

The expanding is done by the function hashHandler() on line 164 of jquery.makeCollapsible.js. It specifically removes mw-collapsed from elements that are parent to the anchor link's id location. So, the options are to reverse it (as mentioned above) or completely remove mw-collapsible (toggle) so it is always scrollable and sticky and hope no sticky elements block too much or all of the underlying scrollable data on small mobile screens. Jroberson108 (talk) 20:21, 13 August 2024 (UTC)[reply]

Reversing collapsible's show/hide states worked, so the table stays scrollable and sticky when an anchor/jump link that targets it is used. As I mentioned, the "aria-expanded" attribute true/false value is reversed now. That leaves the background-color !important, assuming they want to use this template. Let me know if you still want the change and I can change it. Not sure if a discussion on the other talk page is needed? Jroberson108 (talk) 21:13, 13 August 2024 (UTC)[reply]

I am not good at a lot of stuff. :)

About the only thing I understand well are your comments about !important. I have been using that a lot lately on the other wikis I edit. So that the Firefox addon, "Dark Reader", works on them without problems. I use a lot of different text highlighting and section background colors.

I finally looked at the various perennial sources table versions (see links in my previous posts) in my iphone SE 2020. The {{sticky table start}} version works badly in both portrait and landscape view. I use a larger font. The first column is just too wide in both views. It almost fills up the whole available scroll-window width in portrait view. And since side sticky is used, even the landscape view is bad. And several columns are wide, making it near useless in landscape view too.

The {{sticky header}} version, on the other hand, works great. Since there is no side sticky, the table can be scrolled horizontally in landscape view, and the table will fill up the whole screen top to bottom, and side to side. No margins, and no scrollbars. And since the top sticky is only 2 lines, it takes up very little space, and does not interfere.

I am thinking we might return the scrollable window option to {{sticky header}}. At least temporarily, or in a sandbox. I would like to see how it looks on the perennial sources table. I am curious to see how much width the vertical scrollbar for the scrolling table window takes up. Also, want to see if there are additional margins compared to {{sticky header}} without the scrolling option. There are many tables with wide columns that need sticky headers. And I now see that {{sticky table start}} will not work with them. For example, the many tables with notes columns.

The background colors are a secondary issue, and if a TemplateStyle is used, then I agree that !important should be used if that is necessary to get a scroll window to work. --Timeshifter (talk) 01:48, 14 August 2024 (UTC)[reply]

With this template you can have top sticky rows and not have a left sticky column if you want. At least if a table has a wide sticky column, you can disable it with this template to see the entire table, but can't disable sticky on {{sticky header}}. I don't understand your remark about a notes column not working. The biggest difference between the two templates is that this one limits how much of the table takes up the page's vertical and horizontal space, has a toggle to disable it, and offers a way to make a column left-sticky. Making row(s) top sticky is the same, just either to the page or div. Jroberson108 (talk) 03:08, 14 August 2024 (UTC)[reply]

Oops, brain fart. Forgot I could disable left sticky on {{sticky table start}}.

About problems with a notes column. Notes column is usually a wider column. Like the summary column in the perennial sources table. It does not fit in landscape view in my iphone in the top and side sticky table. Not enough room. So it is difficult to read that summary column. One has to scroll each line in the summary column. This is why it is better to do without side sticky in this case.

I experimented here with top sticky only:

User:Timeshifter/Sandbox269

I see there that {{sticky table start}} works with the horizontal TOC now. And the expand button worked.

If only the expanded version still had the top sticky. Without that I prefer {{sticky header}}. There is more room.

I can't remember if the scroll window with {{sticky header}} expanded or not. Or if when expanded the top sticky still worked.

I want a top-sticky-only template that can expand, but still have top sticky. --Timeshifter (talk) 05:22, 14 August 2024 (UTC)[reply]

In case you haven't realized it yet, you can also have a left sticky column with no top sticky rows if there is a need. I'm sure at some point someone will use it just for the scroll with no sticky rows or column.

The documentation does warn against a wide sticky column: "Avoid making an excessively wide column sticky that might block too much data on narrow screens (ex. mobile portrait)." You mentioned "If only the expanded version still had the top sticky." That defeats the purpose of the toggle to disable the features. Remember, the same problem you experienced with a wide left sticky column can also occur with tall top sticky rows, especially in mobile landscape, which is mentioned in the doc on both templates.

Although it may be possible to keep the top sticky in an expanded state, in that case sticky to the top of the page instead of the div, it sounds like a bad idea because of the before mentioned potential accessibility problem for a sighted person. And to answer your question, {{sticky header}} did not have the toggle, as previously mentioned, so it still has the potential for accessibility problems that cannot be disabled.

Without the ability to disable all, the only way around a wide sticky column or tall sticky rows would be to rotate the phone (landscape vs portrait) granted the sticky column and rows aren't both too large, or maybe switch to desktop view and zoom out (untested and cumbersome).

If others think keeping top sticky in an expanded state won't cause accessibility issues, then it might be possible to change it. Jroberson108 (talk) 12:52, 14 August 2024 (UTC)[reply]

OK. I guess if someone is expanding the sticky table due to the sticky headers extending too far into a cell phone's screen space, then they don't want the same problem after expansion.

I was thinking that someone might want to expand the table for a related reason: To still have the sticky header, but also to have a little more space for the table. No space lost due to the scroll bar, or the max-height: 75vh; setting.

I wonder if it is possible to have 2 options: One to expand the table, but keep the sticky headers. The second option disables the sticky headers. 2 buttons: "Expand" and "Disable". And their opposites after toggling.

That's interesting. With "disable" by itself one ends up with a simple scroll window. That is useful by itself. It makes going up and down the page faster. One can bypass the table quickly.

One can stop and re-enable the sticky headers if they want. Those headers may still be better than doing without them. Even if they are big. And then expanding the table may give just enough space to make it workable. Reader has to decide.

I just want to say that I looked at the template CSS to try and figure out something. I see again that you have done a massive amount of work. Thanks! --Timeshifter (talk) 20:26, 14 August 2024 (UTC)[reply]

You're welcome. Having two buttons would be the equivalent to wrapping the table in two collapsible divs. That would be very tricky to manage with four states: collapsed/enabled, collapsed/disabled, expanded/enabled, expanded/disabled. It sounds like overkill to me. The documentation gives guidance on what to avoid so the need to disable is less likely, which again would most likely only be needed on mobile and in certain cases. If many users find the disable or enable options problematic or not enough, then it can be looked into. Jroberson108 (talk) 20:34, 14 August 2024 (UTC)[reply]

Bug report: mw-datatable not highlighting rows

@Timeshifter:, your addition of the row highlighter, was highlighting the table's rows for a day or so before it stopped working. I assume it is from a recent update (which replaced expand/collapse with enable/disable in {{sticky table start}}. Qwerty284651 (talk) 19:09, 14 August 2024 (UTC)[reply]

Qwerty284651. Good catch. Thanks.

Jroberson108. I did a test on the top doc table at Template:Sticky table start. See:

http://en.wiki.x.io/w/index.php?title=Template:Sticky_table_start/doc&oldid=1240319299

Table has a white background, but row highlighting (via hover) is gone. --Timeshifter (talk) 19:56, 14 August 2024 (UTC)[reply]

@Qwerty284651 and Timeshifter: Fixed. Jroberson108 (talk) 22:01, 14 August 2024 (UTC)[reply]

Thanks. Qwerty284651 (talk) 22:54, 14 August 2024 (UTC)[reply]

Need help with class="sticky-table-unsticky"

Can the bottom table in User:Qwerty284651/sandbox#Examples span issues with sticky headers be resolved with class="sticky-table-unsticky" on mobile? I tried adding it to the cells that start with the span but because the 1st column is using rowspan and the 2nd one isn't, it's not resolving the span issue. Is the top table fixed because it has matching rowspans that fall in the same row? Qwerty284651 (talk) 21:26, 20 August 2024 (UTC)[reply]

@Qwerty284651: Adjusted the tables a bit. The "sticky-table-unsticky" class removes sticky, not add it. On the second table, if you are wanting to also make the "Margaret Court" cell left sticky, which is technically in column one due to the preceding rowspan (no preceeding cells), it can't be done without adding a new class to the template to make a cell left sticky. You are going to have unpredictable results when it comes to having rowspan or colspan prior to a sticky cell. The alignment is also off on that same cell and the "26" cell next to it for the same reasons: see Template:Table alignment/doc#Limitations. Easiest might be to move the "Player" column to the left most since that seems to be the row header. Jroberson108 (talk) 23:39, 20 August 2024 (UTC)[reply]

I solved the span issue by making the first 2 columns sticky and then adding class="sticky-table-unsticky"| to overlapping data cells during horizontal scrolling.

See another example: table 1 using the trick: (both cols sticky with unsticky class) in comparison with table 2; table 3 and table 4, which have the (2nd col only sticky without the unsticky class) in mobile portrait. Qwerty284651 (talk) 10:57, 21 August 2024 (UTC)[reply]

@Qwerty284651: That's an interesting way to fix it that I would not have considered since the col1 and col2 classes weren't originally meant to be used together due to stacking. See doc. I guess due to the addition of the "sticky-table-unsticky" class, the stacking can be removed. If it works, then OK. Jroberson108 (talk) 18:35, 21 August 2024 (UTC)[reply]

Note, that fix works only if column 1 is narrower than column 2, otherwise it is visible behind column 2 due to being sticky. In those cases, column 1 would need unsticky too.

The alternative is to only make column 2 sticky, then apply a new class to individual cells to make them left sticky, which would only be needed on column 2 cells affected by rowspan. Column 3+ would still use unsticky to prevent stacking above column 2. Jroberson108 (talk) 20:11, 21 August 2024 (UTC)[reply]

Is the class=sticky-header| the class you are referring to that makes cells left sticky? Qwerty284651 (talk) 20:43, 21 August 2024 (UTC)[reply]

@Qwerty284651: No, that class belongs to {{sticky header}}. I am talking about adding a new class to this template, maybe sticky-table-left, that would be applied to individual cells affected by rowspan so they are left sticky too. Maybe also rename sticky-table-unsticky to sticky-table-none so it follows the same naming convention. Jroberson108 (talk) 21:00, 21 August 2024 (UTC)[reply]

Isn't the CSS code of {{sticky header}} embedded in {{sticky table start}}? Or is that a separate, albeit similar thing?

Would not that be more confusing for newcomers seeing all those classes sticky-table (-none, -left, etc.) that have no idea about sticky (row and column) headers? On the other hand, if only sticky-table-rowN/colN is used in combination with a new sticky-table-<insert name here> would bypass stacking, presumingly.

Renaming it to sticky-table-none would restore the span issues in all tables, that are currently using sticky-table-unsticky to fix the overlapping/stacked data cells. The same naming convention compared to what class? Like border-none? Qwerty284651 (talk) 21:18, 21 August 2024 (UTC)[reply]

@Qwerty284651: {{Sticky header}} is a different template with different class names (not embedded). Although similar styles for top sticky rows, this template does it in a div that fixes an Android issue mentioned on the other template. This one also offers a left sticky column, something not possible without the div. This one also allows you to disable the styling if sticky elements cause readability issues on small screens. Originally, {{sticky header}} was going to be replaced/deleted by this one, which I still believe it is obsolete, but Timeshifter believes it is still useful from what I understand. The two templates should not be used on the same table.

The documentation would explain the classes, as it does now. I'm not removing the current classes, only adding one for making a cell left sticky and renaming the other that is also applied to a cell. Renaming would apply to usage too, which is less than a dozen pages. Those two cell classes are only needed to make a column left sticky when rowspan causes issues. Naming convention like float and other's with a "none" value. Jroberson108 (talk) 21:45, 21 August 2024 (UTC)[reply]

@Qwerty284651: I added the sticky-table-left class since there is a need to fix issues when a static column 1 uses rowspan and column 2 is sticky. Give it a try. This avoids making both column 1 and 2 sticky and having a wide column 1 show behind column 2 when stacked. I also added sticky-table-none and will replace the usage of sticky-table-unsticky. The documentation has been updated. Jroberson108 (talk) 22:24, 21 August 2024 (UTC)[reply]

Having only the 2nd column sticky in combination with sticky-table-left and sticky-table-none gets the job done.

P.S. Without having both columns sticky, it is a bit more time consuming having to manually add sticky-table-left to all cells that need to be sticky instead of just having sticky-table-col1 and sticky-table-col2. Just an observation. Qwerty284651 (talk) 01:50, 22 August 2024 (UTC)[reply]

@Qwerty284651: Good to know that it works. At least using sticky-table-left should be right next to sticky-table-none, and only used when column 2 is sticky with rowspan issues from column 1, which I suspect to be uncommon. Jroberson108 (talk) 02:30, 22 August 2024 (UTC)[reply]

The reverse of it (when column 2 is sticky and uses rowspan instead of column 1) does not require sticky table left, only sticky table none for overlapping/stacking cells, if any.

Also, combining sticky-table-col1 and sticky-table-col2 no longer works as it disables sticky columns. Qwerty284651 (talk) 13:37, 22 August 2024 (UTC)[reply]

@Qwerty284651: Your comment about sticky-table-none and column 2 rowspan is correct for any sticky column, and the issue is mentioned in the doc next to that class.

I disabled the combining of col1 and col2, as the doc indicates (limit 1) because of the stacking issue mentioned above and on the doc. If column 1 is wider than column 2, it is still visible. Instead, sticky-table-left should be used, which doesn't have that potential issue. Jroberson108 (talk) 18:59, 22 August 2024 (UTC)[reply]

I implemented the new solution/workaround with sticky-table-left and sticky-table-none on 4 pages: chart 1, chart 2, chart 3 and chart 4 (same charts as discussed above). They work like a charm. Qwerty284651 (talk) 16:18, 23 August 2024 (UTC)[reply]

Border missing with static row numbers

Border is missing in 1st column between the merged col headers and "1" cell when combining with {{static row numbers}}. When {{sticky table start}} is disabled, the border displays as expected. Qwerty284651 (talk) 12:40, 22 August 2024 (UTC)[reply]

@Qwerty284651: Already discussed at #Tests of new template. Jroberson108 (talk) 18:46, 22 August 2024 (UTC)[reply]

Glad to know there are testcases already on the subject. Qwerty284651 (talk) 16:11, 23 August 2024 (UTC)[reply]

Pages with many long and wide tables

There are a lot of pages like this with many tables on the page:

List of Intel graphics processing units

Scroll down to the long, wide tables. For more such pages:

That is if you want something to work or experiment on. This is also a note to myself if I find the time.

There pages all have one or more long tables, though not necessarily wide tables:

Category:Lists of countries
Lists of sovereign states and dependent territories. "a list of lists of countries and territories by various criteria."

And by US state:

They mix up pages with lists of US states by topic; with individual state pages by topic. --Timeshifter (talk) 06:14, 23 August 2024 (UTC)[reply]

Bug?: show/hide button missing in collapsed table

The hide/show button in the following collapsed table is missing in both desktop and mobile view. Also, collapsible disables sorting.

Enable/disable button doesn't do anything on mobile. Qwerty284651 (talk) 01:50, 31 August 2024 (UTC)[reply]

@Qwerty284651: Per MOS:PRECOLLAPSE and MOS:DONTHIDE, the table (content) should not be collapsed (mw-collapsed class) by default since that causes accessibility issues for screen readers. Also, this template uses mw-collapsible for the disable/enable toggle, except it doesn't fully hide the content and has a max-height that is easy to scroll past. Adding another mw-collapsible is going to cause issues. I suggest using one or the other. Jroberson108 (talk) 03:58, 31 August 2024 (UTC)[reply]

Also, seems like your caption is messed up. You have it as a single cell data row (sortable needs top header rows) instead of using the caption markup, which might be causing sorting/sticky issues. Jroberson108 (talk) 04:05, 31 August 2024 (UTC)[reply]

When I edit/preview that section and fix the caption, the buttons work and the table is both sticky and sortable. This template shows the mw-collapsible buttons when the browser is less than 640px wide. But again, I wouldn't use both. Jroberson108 (talk) 04:14, 31 August 2024 (UTC)[reply]

I modified the styles so that if someone does want to add the mw-collapsible class to the table too, then the disable/enable buttons are hidden at >= 640px width while the hide/show buttons are always visible. Jroberson108 (talk) 04:54, 31 August 2024 (UTC)[reply]

Thanks for the clarification regarding mw-collapsible and mw-collapsed.

You fixed my caption issue with class=nowrap|. Which is better {{nowrap}} or the namesake class or it's all the same? Qwerty284651 (talk) 01:16, 1 September 2024 (UTC)[reply]

@Qwerty284651: They both use the same class. The template just encapsulates the content with a span tag that has the class. If the entire caption is short, then I would just use the class for less markup. For a longer caption on a narrow table, you may need to use {{nowrap}} on some of the caption so the table width isn't wider than it needs to be. See Help:Collapsing#Tables with captions. Jroberson108 (talk) 04:25, 1 September 2024 (UTC)[reply]

This only matters for fully collapsed tables. On sticky tables class=nowrap| does nothing for the caption. It already doesn't wrap to the screen width. The table caption will wrap to the table width. I mention this mainly for others reading this thread later. Because I have noticed class=nowrap| on various table captions even though it doesn't do anything for those tables. And it would not be logical to use class=nowrap| to force a caption to extend past the table width. class=nowrap| can be used for individual table column headers, but not for table captions. --Timeshifter (talk) 14:46, 1 September 2024 (UTC)[reply]

The documentation at Help:Table or Help:Table/Advanced should be updated to distinguish between class=nowrap and style=whitespace:nowrap when used inside table cells vs table caption. Qwerty284651 (talk) 16:45, 1 September 2024 (UTC)[reply]

Feel free. Table captions, column headers, table cells, etc.. --Timeshifter (talk) 21:49, 1 September 2024 (UTC)[reply]

Disable scroll window. And: Enable sticky headers

I think the disable and enable buttons need to be clearer. I think there is room since nothing else is on the same line?

Suggestions: "Disable scroll window". And: "Enable sticky headers"

I think that would be clearer on my iphone SE 2020. For example here:

List of US states by minimum wage#Consolidated minimum wage table

By the way, that page section table can not use sticky row headers, since the first column does not consist of row headers. --Timeshifter (talk) 18:15, 2 September 2024 (UTC)[reply]

@Qwerty284651: since you've been involved with this template lately, do you have an opinion on this? Mine is that disable/enable seems as clear as collapsible's hide/show. Once clicked/pressed, the reader will quickly know what it is for and it isn't hard to remember.

What is disabled and enabled is both the scrolling div and the sticky cells, which aren't necessarily headers. Other things get disabled too like the border fixes. Jroberson108 (talk) 19:39, 2 September 2024 (UTC)[reply]

When I came across it on my cell phone today, I thought "disable" was confusing. As in disable what? I can see how some would just scroll by and not even realize they missed a table. The header fills in the whole screen. Granted, after using it, it is clear. But non-regular Wikipedia readers may forget.

Other possibilities: "Open table up." ...

I assume that a row or column can be made sticky even if not a header row or column. So "enable" in almost all cases is enabling what in effect become sticky headers. So "Enable sticky headers" seems most clear. I think it will be rare to see only a scrolling table, without sticky headers at all. --Timeshifter (talk) 20:42, 2 September 2024 (UTC)[reply]

I thought about it and am gravitating towards the former "Expand/collapse", which, admittedly, might get confused with "show/hide" as they sound similar. Alternatively, something along the lines of the following can be used:

1. For expand: "show entire table", "expand table", "reveal table", "disable sticky headers"..

2. For collapse: "fit table to screen", "collapse table", "shrink table", "restore small table", "enable sticky headers"...

Can't any data cell be made sticky with class=sticky-table-left? Qwerty284651 (talk) 22:41, 2 September 2024 (UTC)[reply]

See above mentioned table. Added extra text in 1st data cell to force the table to expand beyond the page's width in mobile portrait. Qwerty284651 (talk) 23:09, 2 September 2024 (UTC)[reply]

Yes, any cell can be made sticky or not sticky, not just headers. The same goes for a single row or column. However, for the sticky-table-head option, sortable and the sticky gadget only move consecutive header rows into the thead, so that's always headers even if misused for say a totals header row that normally should be a sorttop data row or a caption in a top header row that should be caption markup. Sortable also moves sorttop data rows into the thead after sorting, so those become sticky too.

Also, although the template is built and named for tables, it isn't limited to usage for tables. It is possible that the scrollable div can be used on something else that has no need for sticky like a large graph that extends beyond the desktop's main content area, albeit predictably rarely used on non-tables. I may have questioned what the hide/show links were when I first came across them, but it was quickly and permanently answered with a single click.

The former expand/collapse was changed to the current disable/enable for accuracy because this template can be used unnecessarily on a narrow, short table or used on one that is narrow but tall that won't "expand" noticeably without scrolling down to compare. In essence, the links disable/enable this template's styling/features and the links are only visible on smaller screens like mobile to give the reader a way to disable what might be causing a readability issue, if any. Jroberson108 (talk) 02:25, 3 September 2024 (UTC)[reply]

Because its application expand beyond just tables, maybe renaming to of its existing shortcuts {{sticky top}} or {{sticky start}} would best reflect its usage, which consequently might not be immediately intuitive that it is used for tables, primarily, if "table" is removed from the title. Qwerty284651 (talk) 01:58, 5 September 2024 (UTC)[reply]

Well in that case, the "sticky" part doesn't apply. Sticky is only used in tables. For non-tables, it's just the scrollable div. Jroberson108 (talk) 03:36, 5 September 2024 (UTC)[reply]

Jroberson108. Could you give an example table here or elsewhere (version link) that uses class=sticky-table-left?

And is the only certain thing about this template is that it is in a scroll window? If so, then could the buttons be called "disable scroll window" and "enable scroll window"?

This would make the buttons distinctive from show/hide toggle buttons, and expand/collapse toggle buttons, which are used on fully collapsed tables for the most part. And never on scroll windows. --Timeshifter (talk) 03:13, 5 September 2024 (UTC)[reply]

@Timeshifter, you can find some examples here: (1, 2, 3, 4) which are using class=sticky-table-left. Qwerty284651 (talk) 03:50, 5 September 2024 (UTC)[reply]

If you want to know where sticky-table-left is used, you can just search for it. It was recently added.

Again, it doesn't just disable/enable the scroll window. The names differ from hide/show, so it is already distinctive. There are no expand/collapse buttons. Jroberson108 (talk) 03:52, 5 September 2024 (UTC)[reply]

Addendum: expand/collapse was renamed to disable/enable.

Those are the tables I linked to in my examples in the comment above. Qwerty284651 (talk) 03:57, 5 September 2024 (UTC)[reply]

I think bringing up expand/collapse earlier might have caused some confusion. Looks like your links are the same as the search, which would show more uses beyond your own. Jroberson108 (talk) 04:26, 5 September 2024 (UTC)[reply]

I did not know that expand/collapse is no longer used anywhere on Wikipedia.

Thanks for the insource search link. I used a couple insource search links in Template:Sticky table start/doc‎. I also added another table example from an article.

I understand that Template:Sticky table start does more than add a scrolling window. My point is that it does it in all cases of its use.

The meaning of show/hide is obvious. The meaning of enable/disable is not. Though it is distinctive. I want more meaning, and there is room. Adding a couple more words hurts nothing, and helps readers who don't see these scrolling tables often (which right now is almost everybody). It helps irregular Wikipedia readers even more.

disable scroll window and enable scroll window. --Timeshifter (talk) 17:16, 5 September 2024 (UTC)[reply]

I agree with the proposed names above. Qwerty284651 (talk) 17:40, 5 September 2024 (UTC)[reply]

How about "disable scroll/sticky" and "enable scroll/sticky" so we don't have a repeat of #Expanded table is not sticky. Also, background colors removed? My issue is that you only refer to the scroll, which is no different than naming it expand/collapse that implies that the sticky should still work per the linked discussion. That's why it is simply "disable" and "enable". I highly doubt disable/enable or "disable scroll/sticky" and "enable scroll/sticky" will cause any real confusion beyond this hypothetical discussion, especially after clicking the link.

Also, in your second example, using color as the only means to convey data (Active or Defunct tournament) is not accessible for screen readers. Jroberson108 (talk) 19:58, 5 September 2024 (UTC)[reply]

I am trying to ensure that they click the link.

I like "disable scroll/sticky" and "enable scroll/sticky".

--Timeshifter (talk) 20:42, 5 September 2024 (UTC)[reply]

Table design discussion

Moved to Talk:WTA 1000 Series singles records and statistics#Table design discussion

Reenable class stacking

Can you reenable class stacking so I can use both sticky-row1 and sticky-row2 in WTA 1000 Series singles records and statistics#Title leaders? Because of the latest edits sticky-left and sticky-none useless can't fix the span issues in mobile. Related discussion for sticky-table-left and sicky-table-none classes in #Need help with class="sticky-table-unsticky".Qwerty284651 (talk) 18:34, 6 September 2024 (UTC)[reply]

@Qwerty284651: That won't fix your issue. Because of the rowspan, you have to use sticky-table-head to make both rows top sticky. If row1 and row2 were used, the botton of the rowspans would stick out below row2 once the latter is sticky. Jroberson108 (talk) 23:57, 6 September 2024 (UTC)[reply]

That solved it. Qwerty284651 (talk) 00:11, 7 September 2024 (UTC)[reply]

I would update the doc that "adding sticky-table-row1 or -row2 disables sticky-table-head's feature of making both rows sticky". See example. Qwerty284651 (talk) 00:15, 7 September 2024 (UTC)[reply]

It does say limit one and don't combine and gives reasons. More can be added, but they need to read it. Jroberson108 (talk) 00:17, 7 September 2024 (UTC)[reply]

It does say that. Now I know. Qwerty284651 (talk) 00:23, 7 September 2024 (UTC)[reply]

Visual editor issues

It seems like Template:COVID-19 pandemic data/United States medical cases by state has become harder to edit visually after using Sticky Table. I would appreciate if you know how to resolve this. Horizon Sunset (talk) 16:55, 12 October 2024 (UTC)[reply]

@Horizon Sunset: I'll try to look at it later. Can you explain how it is harder to edit so I know what to look for? Jroberson108 (talk) 17:03, 12 October 2024 (UTC)[reply]

If you go to my sandbox (which had the version before your edits, except I removed the invalid .css which you also removed) and click on visual editor, you can edit each cell's data. But if you go to Template:COVID-19 pandemic data/United States medical cases by state and click on "Edit with visual editor", it shows that you are editing parameters of a template instead. I am trying to make this better by reducing number of parameters within the table. Horizon Sunset (talk) 22:12, 12 October 2024 (UTC)[reply]

@Horizon Sunset: I moved the discussion to this template's talk so other's are also aware.

I narrowed the issue down to having two opening div tags in the start template and two closing div tags in the end template. Adding the div tags around the table without the template did not cause an issue. Removing one of the two div tags from each template did not cause an issue, so VE might be doing some minimal correction in it's parsing.

VE has a list of "Template issues" at Wikipedia:VisualEditor#Limitations, specifically "Unbalanced code". I don't see a way to exclude the div tags from VE. Jroberson108 (talk) 01:41, 13 October 2024 (UTC)[reply]

@Horizon Sunset: I started a discussion at Wikipedia talk:VisualEditor#Exclude transcluded unbalanced code. Will see if a solution exists. Jroberson108 (talk) 02:23, 13 October 2024 (UTC)[reply]

@Jroberson108: I really appreciate that, thank you so much:). Horizon Sunset (talk) 02:40, 13 October 2024 (UTC)[reply]

Have you tried putting the sticky table templates inside <includeonly>...</includeonly> tags on the template page? That might make it editable while maintaining the features you want when it is transcluded. – Jonesey95 (talk) 20:20, 20 October 2024 (UTC)[reply]

@Jonesey95: I assume from your sandbox edits that you saw the tags already exist in each template. Jroberson108 (talk) 10:41, 22 October 2024 (UTC)[reply]

I haven't tried includeonly tags in the sandbox. I just added them to Template:COVID-19 pandemic data/United States medical cases by state/sandbox. Is that editable with VE? – Jonesey95 (talk) 14:41, 22 October 2024 (UTC)[reply]

@Jonesey95: This template and {{sticky table end}} both already have includeonly tags in them, also in their sandboxes too. Template:COVID-19 pandemic data/United States medical cases by state/sandbox seems editable with VE now, although adding "includeonly" tags around the template transclusions doesn't seem feasible for other pages. Jroberson108 (talk) 15:58, 22 October 2024 (UTC)[reply]

Yes, I know about the tags in Sticky table start, but those don't matter once the template is transcluded somewhere else. Excluding the Sticky table templates from rendering on the page where the table needs to be edited appears to work around this shortcoming in VE. You don't give an example of a page where it is not feasible, so I can't comment on that assertion. – Jonesey95 (talk) 16:31, 22 October 2024 (UTC)[reply]

@Jonesey95: Not being feasible is in regards to having to add it to all 314 pages that transclude this template as well as expecting editors to add these extra tags around future transclusions, something I have yet to see done in this way with other templates. I see at Wikipedia talk:VisualEditor#Exclude transcluded unbalanced code that another person said there is no easy and reliable way to fix it. Minimum, a note can be added to the doc explaining VE's issue. Jroberson108 (talk) 02:10, 23 October 2024 (UTC)[reply]

If you don't want to implement this workaround, then putting a note in the documentation is probably the way to go. I found {{Vedit notice}}, but I did not find a similar standardized template that states the opposite (which surprised me). – Jonesey95 (talk) 02:19, 23 October 2024 (UTC)[reply]