Template talk:2020 monthly cumulative COVID-19 death totals by country

Latest comment: 2 years ago by Timeshifter in topic 2020, 2021, and 2022 templates and sandboxes

Note: See further discussion at Talk:COVID-19 pandemic deaths.

Need CSS help to get narrower table

edit

Please see discussion here:

Scroll down to the narrower table. --Timeshifter (talk) 10:00, 24 October 2020 (UTC)Reply

This problem has been solved. See above-linked discussion. --Timeshifter (talk) 20:14, 4 November 2020 (UTC)Reply

Updating this table

edit

Thanks to Anguswalker for maintaining this table:

I copy it to this sandbox:

Then I adapt it for use in this template:

This template is used here:

--Timeshifter (talk) 20:13, 4 November 2020 (UTC)Reply

Table now has a separate header row for sorting icons

edit

This has been done to narrow the table. Even with this narrowing the table barely fits now in one of my monitors, the 21 inch monitor.

I use this sandbox now:

If I forget to update the table when the first of the month comes around, please ping me, and I will update the sandbox and main template. Or leave a note on my talk page. --Timeshifter (talk) 12:47, 18 December 2020 (UTC)Reply

Separate row for sorting icons is not needed in the 2021 table. Since the cumulative numbers are wider than the header text. --Timeshifter (talk) 04:18, 7 April 2021 (UTC)Reply

2020, 2021, and 2022 templates and sandboxes

edit

See: Help:Table#Picking selected dates from massive .csv files. Follow those instructions to update the 2022 table. Copy that table from from tab2wiki to a user sandbox.

Then see: Help:Table#Adding flags and linking country names in country lists and the following section. After following those instructions, and correcting errors in the sandbox table, copy the table data to this 2022 scrolling template:

  • See: <!-- Insert updated data below this line --> in the above-linked template.

Check that the 2022 template, and the other scrolling templates, are working correctly here:

The 2022 table template is used in these 2 Wikipedia articles:

The last article also contains these scrolling table templates:

2021:

2020:

It is not possible to make the "World" row into header cells. This messes up the scrolling of the template. The template is supposed to only make the first column header row sticky when scrolling. --Timeshifter (talk) 20:06, 7 January 2022 (UTC)Reply

Some of the above info is out of date because the templates have been converted to scrolling templates.
For more info see:
User:Timeshifter/Sandbox173
--Timeshifter (talk) 18:58, 8 February 2022 (UTC)Reply

Second column ("Jan") is left aligned

edit

I'm not sure why but reporting the visual bug.

 
In the screenshot the column "Jan" is left aligned while other months are right aligned.

 AltoStev Talk 14:33, 5 November 2021 (UTC)Reply

Thanks, AltoStev. I am asking Tol if his last few changes to CSS may be the reason. See:
Template:COVID-19 pandemic death rates/styles.css
Template:COVID-19 pandemic data/styles.css
The 2 tables linked below have the same problem with the second column.
Multiple tables including those below are on the same page using the same CSS style sheets linked above:
Template:Monthly cumulative COVID-19 death totals by country
Template:Monthly cumulative COVID-19 death totals by country 2021
Here is the page:
COVID-19 pandemic by country and territory
--Timeshifter (talk) 22:37, 5 November 2021 (UTC)Reply
@AltoStev & @Timeshifter: The template uses TemplateStyles from Template:COVID-19 pandemic data/styles.css, which center-aligns the first column and right-aligns the second column of tables with ID "thetable". I've made the ID unique instead, which should fix this, but I'd strongly recommend using your own styles instead of those of another template. Tol (talk | contribs) @ 23:51, 5 November 2021 (UTC)Reply
Tol. Thanks! I did not create those style sheets. They are way beyond my knowledge and pay grade. I do the monthly updates. Working on Nov 1, 2021 column now. --Timeshifter (talk) 00:08, 6 November 2021 (UTC)Reply
No problem! Tol (talk | contribs) @ 00:15, 6 November 2021 (UTC)Reply

Mobile sort row

edit

Regarding the edit to add a sorting row to narrow the view for cell phones (mobile browsers), sorting doesn't work on mobile and seems like it hasn't for years from the talk page linked to in the edit. I am using Android Chrome and Firefox. No sort buttons show. All I see is an empty row. For wide tables on mobile, placing a "div" with style="overflow-x: auto;" around the table should be sufficient for responsive design. Also, the headers don't stick to the top on mobile. Jroberson108 (talk) 19:49, 18 December 2021 (UTC)Reply

I see you have posted in this thread too:
https://phabricator.wikimedia.org/T42763
I noticed today some other sticky header threads on Phabricator. Do a search there to see what I mean. I am not sure, but some of them seem to be making more progress.
Just because sorting does not currently work on mobile is no reason not to use it on desktop PCs. Sorting rows have been used on many tables for years. There was a row of sorting icons for a long time in that 2020 table before you tried to remove them today.
style="overflow-x: auto;" does not make the table narrower. Narrower tables are better than just using horizontal scrolling code alone. And we need sticky row headers to make that horizontal scrolling more useful. --Timeshifter (talk) 05:01, 19 December 2021 (UTC)Reply
I didn't suggest not using sortable. I never said style="overflow-x: auto;" would make the table narrower, instead it adds a horizontal scrollbar if needed, which the table already implements for desktop and mobile.
What I was saying is that adding a separate sort row under the column headers' row to save on horizontal space for mobile browsers doesn't make sense because the buttons don't show on mobile regardless of location, but the blank row will show. It makes more sense to keep the sort buttons inline to the right of the column names for desktops (invisible on mobile). If the table didn't have a scrollbar, then having a separate sort row would make more sense for really wide tables on desktop, which is mostly how the sort row is used.
Regarding your emphasis on narrowing, obviously you should simplify the table as much as possible without sacrificing data, clarity, and consistency. In that regard, some people may read the "Dec" column header as all of December as opposed to what it is, "Dec 1". There are also consistency issues where the 2020 table uses "Dec" and a separate sort row while the 2021 table uses "Dec 1" and inline sorting. Jroberson108 (talk) 08:14, 19 December 2021 (UTC)Reply
On my ipad I can only see through part of "Sep 1" column with your last revision.
I can see through November with the separate sorting row, and without the dates. So the sorting row is helping with wide tables. People hate scrolling with horizontal scrollbars. I do. Especially without sticky row headers. I wish the developers would prioritize it.
{{Import-blanktable}} allows one to tap on a row and see it highlighted. In my ipad (Safari) and iphone (Edge). So I can pull the chart over to see more rows and not lose my place.
I increase the font size on my desktop. That makes the table wider. So that is another reason to use sorting rows for wide tables.
The day numbers make the columns wider for Jan, Feb, and Mar of the 2020 table. That is why the 2021 table uses the day numbers, and the 2020 table does not.
We could divide the 2020 table into 2 parts as with the 2021 table. Then the day numbers could be used on the 2020 table too. And the sorting row could be eliminated.
But please do not remove sorting rows from wide tables unless you are also willing to divide the table into narrower tables.
Feel free to divide the 2020 table into 2 parts. Please remember to put the last column in each 2020 table as the column in initial sort order. That can be done in a spreadsheet. I use freeware LibreOffice Calc. See:
Help:Table#Sort alphabetically or numerically with free spreadsheet and VE.
--Timeshifter (talk) 14:38, 19 December 2021 (UTC)Reply
According to this Wikipedia usage report, about 71% of pageviews are from desktops, which is probably why developers don't prioritize mobile issues. Splitting tables of simple data, sacrificing relevant information, moving sort buttons to a separate row, and creating accessibility issues, which are partial workarounds focused on certain device sizes that only work in-part, aren't real fixes in the grand scheme of devices. Maybe a larger discussion with other users is needed, which can cover responsive web design that targets all devices. The real fix, which you hint at, should be on making column and row headers sticky so it works regardless of device.
I mentioned on T42763 that, with the exception of a few rare bugs with multi-tiered headers on mobile devices, I got headers to be sticky in my sandbox. I've implemented my version of the 2020 and 2021 tables with top-sticky column headers, left-sticky row headers (locations), and a left-sticky "Location" column header for the row headers. I am still refactoring, reworking, and testing my code. The "Directions" section gives instructions for users to include the CSS/JS so it might work if they view my sandbox.
My demonstration shows that left-sticky row headers are doable with the COVID-19 tables. I played around with modifying this template's table and it doesn't seem possible to make row headers left-sticky due to its CSS applying top-sticky to all "th" cells without checking "thead"/"tbody" or "scope". The CSS prevents the row headers from being coded as headers for accessibility (<th scope="row"></th>). The CSS file needs some parts reworked. Jroberson108 (talk) 17:50, 19 December 2021 (UTC)Reply
You could start a wiki on Shoutwiki. It's free. Call it a "Mediawiki testing" wiki. Then others could see what you are doing without having to install and reinstall your evolving CSS and JS into their user CSS and user JS pages. I have a wiki on Shoutwiki. The person who starts a wiki basically "owns" it, and has final say on everything. So there would be no problem editing the site CSS and JS. There are other wiki farms that provide free wikis.
Phabricator has many "sticky" tasks. See this search:
https://phabricator.wikimedia.org/search/query/iv9Q3sX8Hiv7/#R
Most of the related CSS and JS is way beyond my skill level and understanding. I just look at the results. I am baffled as to why the sorting icons are not automatically placed below the column header text. Without using a separate row. See:
Help:Sorting#Sorting buttons in a separate row
T35249. Sorting icon needs to be below the table header text to keep tables narrower, and for screen readers.
--Timeshifter (talk) 20:23, 19 December 2021 (UTC)Reply

Creating a new wiki site seems like overkill to me. I don't have any reason to doubt the purpose of the "How do you install user scripts?" page is to run other user's scripts. I'm surprised that you are the only one that bothered to respond on T42763, given the number of followers. I may be wrong, but to me it looks like a lack of interest and/or knowledge. Not much help. Anyways, moving on.

Regarding your desire to move the sort buttons under the header text without a sort row, it's a good idea. I played with the CSS a little and got it to work. You have to remove the separate sort row and add this style to each header that has the sort button, which moves the sort button to the bottom with spacing and resets the right spacing back to what "wikitable" sets:

! style="background-position:bottom 6px center; padding-bottom:21px; padding-right:0.4em;" |

For "unsortable" headers, add this style so the text is vertically aligned with the sortable headers:

! class="unsortable" style="padding-bottom:21px;" |

I did a quick test on this table using Windows Chrome and the sort buttons moved under the text with the table width unchanged. The only minor issue I saw was that after sorting, the up sort arrow is slightly too low; not a big deal since clicking the entire cell executes the sort. Feel free to test it. Alternatively, the styles could be added to this template's CSS file so you just have to add a class to the table to apply the chages.

These are the changes to implement in the table if you want to do them. Remove the separate sort row and replace the column headers with this:

! style="background-position:bottom 6px center; padding-bottom:21px; padding-right:0.4em;" | Location
! style="background-position:bottom 6px center; padding-bottom:21px; padding-right:0.4em;" | Jan
! style="background-position:bottom 6px center; padding-bottom:21px; padding-right:0.4em;" | Feb
! style="background-position:bottom 6px center; padding-bottom:21px; padding-right:0.4em;" | Mar
! style="background-position:bottom 6px center; padding-bottom:21px; padding-right:0.4em;" | Apr
! style="background-position:bottom 6px center; padding-bottom:21px; padding-right:0.4em;" | May
! style="background-position:bottom 6px center; padding-bottom:21px; padding-right:0.4em;" | Jun
! style="background-position:bottom 6px center; padding-bottom:21px; padding-right:0.4em;" | Jul
! style="background-position:bottom 6px center; padding-bottom:21px; padding-right:0.4em;" | Aug
! style="background-position:bottom 6px center; padding-bottom:21px; padding-right:0.4em;" | Sep
! style="background-position:bottom 6px center; padding-bottom:21px; padding-right:0.4em;" | Oct
! style="background-position:bottom 6px center; padding-bottom:21px; padding-right:0.4em;" | Nov
! style="background-position:bottom 6px center; padding-bottom:21px; padding-right:0.4em;" | Dec

Jroberson108 (talk) 15:02, 20 December 2021 (UTC)Reply

I just remembered that the styles don't ignore mobile where sortable doesn't work to begin with, so there is extra space. The styles will need to be added to the template's style sheet so mobile can be ignored. You can test the code on a sandbox, then it can be added to the CSS file. Jroberson108 (talk) 15:21, 20 December 2021 (UTC)Reply
Please do not experiment with the template styles for this scrolling template, and the other scrolling templates. They effect the multiple scrolling templates in this article:
COVID-19 pandemic by country and territory.
I didn't create the CSS, but I tested if the scrolling templates were playing well together here:
User:Timeshifter/Sandbox127
See discussion:
User talk:Tol/Archives/2021/12#Firefox. Scrolling table with sticky header missing header cell borders
CSS involved with the scrolling tables in that article:
Template:COVID-19 pandemic data/styles.css
Template:COVID-19 pandemic death rates/styles.css
Template:Import style
Template:Import style/sticky.css
Also, this 2020 scrolling template is not being used in any article currently. But I want to keep it as is. Please do not edit it further in any major ways. Because it is referenced in various discussions and tests.
You can use sandboxes and other user subpages for tests. I have almost 200 user sandboxes. I keep the ones that are referenced in other discussions, or otherwise linked to.
See: Help:Table#Tables and the Visual Editor (VE). Excerpt:
Sandboxes help a lot. For example; your user page: Special:MyPage. Create and bookmark some personal sandboxes too. Visual Editor will load very fast in empty sandboxes: Special:MyPage/Sandbox, Special:MyPage/Sandbox2, Special:MyPage/Sandbox3. As many as you want. Share the link when asking for help. To find all your sandboxes: Special:PrefixIndex/User: – click link, add user name to the spot labeled "Display pages with prefix:".
User subpages are transcludable too. Even without being named "template". I have created some transcludable userboxes on my user subpages. User:Timeshifter/Userboxes.
Did you look at the many other sticky header tasks on Phabricator? I think the reason no one replied was because some of the other tasks look like they are farther along in making progress. Developers seem always to be very busy, and so I am not surprised when there are no rapid replies.
--Timeshifter (talk) 15:50, 20 December 2021 (UTC)Reply
I looked at the search results. Searching for "sticky" is way too broad. The task I am following is the only relevant result I found for sticky table headers that is still open. Also, I never said I would implement any changes in the CSS file, only that it will be needed if your tests of the sort button relocation succeeds so that mobile isn't affected. Thanks for letting me know that this template isn't actually used anywhere. No reason to improve it then. Jroberson108 (talk) 17:00, 20 December 2021 (UTC)Reply
Jroberson108. I returned the max-width CSS, and increased it from 64em to 66em. Table is not wrapping on my large 27 inch screen, nor on my 21 inch screen. max-width just keeps the scroll bar closer to the table. Since it is in em units it works even when the font size is increased (which I do). I set it just large enough to prevent wrapping of the widest row starting with "Saint Vincent and the Grenadines". You can test this in preview. --Timeshifter (talk) 10:14, 21 December 2021 (UTC)Reply
Yeah, 64em was wrapping "Saint Vincent and the Grenadines" for me too, as indicated in my edit summary. It is abnormal to use max-width in that way since it is counter to responsive design, which is why I removed it. I didn't realize you were trying to reposition the vertical scrollbar, which is a nice touch. True, em is relative to font size, but the visual width of the table can be changed by any one of the styles that could modify the margin, border, padding, font size, and kerning. JavaScript, like "sortable", could change the styles. The "flaglist" template could add a missing character to a country or make the flag image slightly wider. Finally, each browser on each operating system has its own set of default styles that vary slightly from others, which could change with each update. I tested on Windows 10 (66em still too small, 70em might better accommodate unknowns).
  • Chrome (before and after sort): 65em wraps; 66em doesn't wrap.
  • Firefox (before and after sort): 67em wraps; 68em doesn't wrap.
There is some extra space between the div and the table, which you can remove by adding padding-right:0; to the div. My new "no wrap" max-width is 65em in Chrome and 66em in Firefox.
A more responsive approach would be to change "66em" to "max-content"; more details. Testing with "Saint Vincent and the Grenadines", Chrome doesn't wrap it while Firefox wraps it for some odd reason. Seems to be a Firefox bug? Jroberson108 (talk) 15:12, 21 December 2021 (UTC)Reply
I figured out the Firefox issue. Need to use overflow-block: scroll;, which Firefox is the only one supporting it right now. So the responsive solution to test on the div is change max-width:66em; to max-width:max-content; overflow-block:scroll; padding-right:0;. Jroberson108 (talk) 18:35, 21 December 2021 (UTC)Reply
Jroberson108. That works great! I can narrow the browser window and it wraps fine. The vertical scrollbar is always right next to the table which causes the least wrapping as the browser window is narrowed. I tested in desktop Win 10 Pro: Firefox, Chrome, Edge. The max-content info page does not mention this use of max-width unfortunately:
https://developer.mozilla.org/en-US/docs/Web/CSS/max-content
It seems overflow-block:scroll; is needed or the Grenadines row will wrap in Firefox even in wider screens.
--Timeshifter (talk) 20:21, 21 December 2021 (UTC)Reply
Here's the link for max-width: max-content;. Jroberson108 (talk) 21:07, 21 December 2021 (UTC)Reply

. Jroberson108. I added style="max-width:max-content; overflow-block:scroll; padding-right:0;" to these scrolling templates too:

--Timeshifter (talk) 07:35, 24 December 2021 (UTC)Reply

Correction, "Template:Monthly cumulative COVID-19 death totals by country 2021 first half" is used now at COVID-19_pandemic_deaths#2021._1st_half. Jroberson108 (talk) 23:38, 7 January 2022 (UTC)Reply

Accessible table notes

edit

@Timeshifter: Your recent edit moved the table note completely outside the div with the accessibility attributes for the table and related content (aria-label="..." role="region" tabindex="0"). This most likely will cause accessibility issues, especially if they tab to that table content (div wrapper). I recommend moving it back and adjusting the note's div styles if you feel the whitespace isn't adequate. Jroberson108 (talk) 21:29, 22 January 2022 (UTC)Reply

It's not really an accessibility problem. Caption is still there. And people soon learn that notes are always above the caption. So when people tab to any table on Wikipedia they learn to scroll up a bit for the notes. --Timeshifter (talk) 23:32, 23 January 2022 (UTC)Reply
@Timeshifter: Caption or a note above the table isn't being discussed. The issue being discussed is accessibility for the table note, which you are excluding the visually impaired by assuming that they should know that there is a table note outside the div their screen reader is currently focused on. You should read more about the attributes: aria-label, region_roles, and tabindex. Jroberson108 (talk) 01:02, 24 January 2022 (UTC)Reply
Why would a person using a screen reader not know that there is more info above and below a table? There is a whole article above and below a table in a Wikipedia article. There are introductions and notes in front of most tables on Wikipedia and elsewhere. The most important thing for tabbing is the caption. --Timeshifter (talk) 04:59, 24 January 2022 (UTC)Reply
@Timeshifter: Again with your arguing of moot points. You obviously haven't tried to use a screen reader and tab to the table only to have the table's note completely skipped, nor have you taken the time to familiarize yourself with the attributes and how they are used for accessibility. Instead of arguing unnecessarily, you should just fix the accessibility issue or ask for help. I fixed the accessibility issue myself. Jroberson108 (talk) 08:38, 24 January 2022 (UTC)Reply
I fixed my problem with accessibility. Which is that even with the 75% vertical height setting I was having difficulty viewing at the 150% text zoom setting in Firefox. There were fewer table rows showing in the table outlined by the scroll bars. So I removed the "Sorted by December" from that area between the scroll bars. It was only recently put in that area by you. It is first found within the scroll bars on Jan 21, 2022.
The rest of the yearly scrolling tables on COVID-19 pandemic deaths have their notes outside the table enclosed by the scrollbars.
I understood your points. I am glad you found a way to add additional accessibility. But most tables on Wikipedia do not have this additional accessibility. Notes are above the caption. And sometimes there are header footnotes going to more info below the table. Even now the note on the 2020 scrolling table is above the caption. So you added some additional accessibility that is not currently in Help:Table.
Feel free to explain this additional accessibility at Help:Table#Scrolling.
Or you could create a user page with the info, and link to it from there. That way you have more room for illustrations, wiki markup, etc.. --Timeshifter (talk) 09:17, 25 January 2022 (UTC)Reply
@Timeshifter: I'm ignoring any moot points. For the record, the accessibility attributes were copied from the other COVID-19 templates I applied the same markup and styles to, but again irrelevant. Obviously new markup was used on this template to apply the new styles, so obviously you work with the new markup. If there is something you don't understand or that looks unfamiliar, then learn it or ask for help. I'm glad you figured out how to fix an issue you had by moving the note outside the scrollable area, but in doing so you created another issue, which is the topic of this discussion. Discussing that issue or your issues that led to the change is preferred over arguing moot points. As far as I'm concerned, this issue has been resolved, so there is nothing more to discuss. Jroberson108 (talk) 12:43, 25 January 2022 (UTC)Reply