Template talk:Sticky table start

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