Template talk:Static row numbers

the column for the "auto-generated static row numbers" is not respecting the theme selected by the user on Wikipedia mobile app

The column for the "auto-generated static row numbers" is not respecting the theme selected by the user on Wikipedia mobile app. The column is shown with white background while rest of the table is shown in dark background when the theme selected on Wikipedia app is dark. I couldn't add the screenshot from mobile app, because Wiki do not consider it as "own work". :D

Seems like CSS issue to me. Some developer must check though.

example -

Assembly Seat No.	Assembly Seat Name	District	Seating Member	Party
118	Baheri	Bareilly	Ataur Rehman		Samajwadi Party
127	Pilibhit	Pilibhit	Sanjay Singh Gangwar		Bharatiya Janata Party
128	Barkhera		Swami Pravaktanand
129	Puranpur (SC)		Baburam Paswan
130	Bisalpur		Vivek Kumar Verma

PyneEditor (talk) 04:16, 26 April 2024 (UTC)

@PyneEditor: I can reproduce it on the Android app. Not sure if you are also using Android? It works correctly on Windows 10 and Android browsers when using the "Dark mode toggle" gadget. I've heard the app has a lot of issues. I don't see much documentation on the mobile app or any indication of where its CSS file is. The issue may be related to one of these open tasks at phabricator or a new one needs to be created? Jroberson108 (talk) 06:01, 26 April 2024 (UTC)

@Jroberson108 I can confirm that issue is on iOS too. PyneEditor (talk) 11:06, 26 April 2024 (UTC)

@PyneEditor: T284327 is related. The background-color is set on the tr::before "cells" due to an inheritance problem per the styles comments: "Windows Firefox tr::before doesn't inherit color, so hard set." Removing it will fix the app, but will make it white on Firefox instead of the gray. Same inherit issue in Chrome. Not sure when they will fix the issue. Here's a link to see the issue without the app. Jroberson108 (talk) 06:35, 26 April 2024 (UTC)

@PyneEditor: I adjusted some of the Minerva styles and it looks like it displays correctly on the Android app. in dark mode/theme. Can you check? Jroberson108 (talk) 08:06, 26 April 2024 (UTC)

@Jroberson108 : It would fix the issue for myself. but bug would still remain for rest of the users. Wikipedia developers should fix the issue for everyone. I can see the last update on https://phabricator.wikimedia.org/T284327 is almost 6 months old. :( PyneEditor (talk) 11:15, 26 April 2024 (UTC)

@PyneEditor: Thanks for indicating iOS app. So the changes fixed it in the iOS app? It fixed it in the Android app. I don't really use the app. except for testing. Jroberson108 (talk) 18:01, 26 April 2024 (UTC)

Remove the 3rd parameter

Remove the static-row-header-hash param as it goes against MOS:HASH. Qwerty284651 (talk) 05:11, 30 May 2024 (UTC)

There is an archived discussion related to this at Template talk:Static row numbers/Archive 1#Replace # symbol. It doesn't seem resolved since there are also issues with using abbreviation with "No.", the other label. Jroberson108 (talk) 09:40, 30 May 2024 (UTC)

I read the past discussion. I don't think there is a need for # or No.

It's pretty obvious it is a fixed column of numbers. It doesn't need any column header at all. Unless it is needed for accessibility. I don't know. Could ask someone who regularly uses a screen reader.

No. is 3 characters and makes the column wider for many state lists. Does anyone actually use it?

If a column header is required, then I think an exception should be made to allow #

It is only one character wide, and so it does not make the column wider. Every little bit helps in keeping tables narrower on cell phones.

Specific exceptions are made at MOS:HASH. And it says "Avoid" use. So it is not an ironclad rule. --Timeshifter (talk) 21:42, 30 May 2024 (UTC)

Ask one User:Graham87 for feedback as a screen reader user. Qwerty284651 (talk) 22:22, 30 May 2024 (UTC)

An option might be to replace both with "Row", which is the shortest thing I can think of that isn't abbreviated. If a label isn't needed, then that could work too, just removing them all together. Keep in mind that it isn't a real column. This template places the label and numbers before the related row, not in it as a regular cell would be. Because of that, a screen reader may not associate the label to the numbers. Jroberson108 (talk) 22:52, 30 May 2024 (UTC)

Yes, a column header is needed for screen readers to interpret the table properly. I don't care what the column header is, as long as there is one. I otherwise don't want to be involved here. Graham87 (talk) 06:46, 31 May 2024 (UTC)

I'm good with always showing a column header. If we can narrow it down to one, then that should remove the need for the "static-row-header-text" and "static-row-header-hash" classes. I lean towards "Row", even if it adds two characters more than "#", because {{abbr}} cant be used for "No." and we can "Avoid using the # symbol" per MOS:HASH. "Rank" could work too since it's possible to skip rows. Jroberson108 (talk) 12:10, 31 May 2024 (UTC)

I don't think "row" is a good description in all cases. When you sort a table the rows change order, whereas the numbering is marking the place in the sequence. I'll also note that MOS:HASH is about the use of the hash in a sentence of the form "she had a #1 hit", which is generally considered poor writing style. On the other hand, the use as a table header for rank/number is widely used. Another possibility is to use # but with the same colour as the background colour, which would appear blank on screen and provide the information to the screen reader.  —  Jts1882 | talk  12:12, 31 May 2024 (UTC)

Jts1882. Ingenious idea. I like it if it works: "Another possibility is to use # but with the same colour as the background colour, which would appear blank on screen and provide the information to the screen reader."

But I also agree with you that "MOS:HASH is about the use of the hash in a sentence". And that in a table header it is not a problem. And therefore I think "No." should be removed as an option due to the column width increase.

Keep the # option. Graham87 says a column header is needed. So I say make it the default, and eliminate any other options. No option to remove it. --Timeshifter (talk) 20:51, 31 May 2024 (UTC)

I can live with "#" being the only label that always displays with no other options, assuming it doesn't go against MOS:HASH, which doesn't specify prose or sentence. I don't see why it should be hidden from the sighted, which makes it less accessible for them and probably goes against MOS:CONTRAST. Jroberson108 (talk) 21:18, 31 May 2024 (UTC)

I agree with @Jroberson108 here. If # does not violate MOS:HASH in non-prose and is WCAG-friendly then I am all for it being retained. Qwerty284651 (talk) 22:31, 31 May 2024 (UTC)

@Qwerty284651:, please encourage people to go to the accessibility talk page, not to ask me. But Timeshifter already well knew about both of these options. Graham87 (talk) 06:46, 31 May 2024 (UTC)

Understood, @Graham87. Qwerty284651 (talk) 06:58, 31 May 2024 (UTC)

Graham87 and all. I had to do some googling just now since I couldn't remember it right away. Here it is:

Wikipedia talk:Manual of Style/Accessibility

--Timeshifter (talk) 20:37, 31 May 2024 (UTC)

How do you add the parameter to align the column left or right?

Instead of having the static number row always centered in the column, how do you make the numbers align left or right? Fyunck(click) (talk) 09:01, 1 June 2024 (UTC)

I don't know. Maybe someone can add a parameter to allow choosing between left, center, or right aligned.

Qwerty284651 recently changed the default from right-aligned to center-aligned. See diff. It happened on May 29, 2024.

I prefer it right-aligned. It keeps the useful part of a table slightly narrower in cell phones. Every little bit helps. --Timeshifter (talk) 09:21, 1 June 2024 (UTC)

Right aligned is usually preferred if number totals are being totaled at the bottom. That would be standard for totaling. But many tables setup by consensus or otherwise use left aligned to go with all the other columns of a table. And this template is also used for desktops and laptops, not just phones. It really needs that flexibility or 1/3 of tables are stuck in one mode. Who would be the best to ask to add the parameter? Fyunck(click) (talk) 09:30, 1 June 2024 (UTC)

I noticed that you just set the default to left aligned.

You wrote: "But many tables setup by consensus or otherwise use left aligned to go with all the other columns of a table." I find many data tables end up being right aligned. Except for the leftmost column of countries, states, provinces, or other text columns. Columns can be easily aligned. See Template:Table alignment.

Maybe Jroberson108 might help. --Timeshifter (talk) 09:56, 1 June 2024 (UTC)

The only caveat to {{table alignment}} is that it doesn't work in tables with col-/rowspan groups as it skews everything up unevely, otherwise it severely saves up on usage of style="text-align....". Very nifty template. Qwerty284651 (talk) 23:29, 3 June 2024 (UTC)

I've restored the right alignment by default and added classes .static-row-numbers-left and .static-row-numbers-center.  —  Jts1882 | talk  10:42, 1 June 2024 (UTC)

I updated the doc page. Qwerty284651 (talk) 01:11, 4 June 2024 (UTC)

Usually numerical data is right-aligned, even if the rest of the table aligns differently. If however all the numbers in the column have the same number of digits like single digit (0-9), then you might see left or center alignment, which isn't noticeable if the column label is empty or the same or less number of characters like "#". Personally, I don't see a need for left or center, but, as mentioned above, it is available now. Also, {{table alignment}} won't be able to align this. Jroberson108 (talk) 12:16, 1 June 2024 (UTC)

The only reason it would right align is so the numbers align when adding up in mathematics, and that's cool. But there are plenty of times you aren't doing those calculations, especially when the column is the very first column of a table. Outside of wikipedia the html easily allows for this flexibility in style, and now that it has been fixed, easily done here too. Thanks for this effort. Fyunck(click) (talk) 18:27, 1 June 2024 (UTC)

It is common for many people to prefer right alignment of number columns even without adding up the numbers. Because it is easier to scan a column this way, and spot the increase in the number of digits. --Timeshifter (talk) 19:13, 1 June 2024 (UTC)

But that would really only apply to large numbers. Sports tables use the first static column to total victories so it will simply be a running total starting with 1 and increasing one at a time to maybe 50. I see no issue in a column that will never have more the two digits and where my eyes scan that just fine left, right, or centered. Only the first nine rows would be single digits. Fyunck(click) (talk) 20:10, 1 June 2024 (UTC)

I work on a lot of country tables. With all kinds of numbers of various lengths in the various columns. In the end it is the table editors that decide what to do. --Timeshifter (talk) 04:13, 2 June 2024 (UTC)

And that makes a big difference. It's why I wondered why it would get changed to "center" a couple days ago. I work on tennis articles where the totals are almost always one or two digits, and you work on articles that have varying number lengths where right justified is helpful to be the norm. Now we have alternatives thanks to editor Jts1882. Cheers and thanks everyone for the quick help. Fyunck(click) (talk) 06:39, 2 June 2024 (UTC)

And also an alternative from me, who boldly changed the alignment to center as, and from this discussion it looks that I am in the minority, I am used to having numbered columns be aligned centered regardless of their position in the table. That is my preference. Funny, how "necessity is the mother of invention" came into full swing here: and Fyunck's and mine edit of the template's css code to center and later left conjured up 2 new classes: .static-row-numbers-left and .static-row-numbers-center. :) Qwerty284651 (talk) 23:26, 3 June 2024 (UTC)

Left/center is simply a matter of opinion and esthetics. Wiki Mos says right is usually best for numbers since they align for addition and decimal points. Same with most google searches (right is preferred), but then none of the examples show a simple column of ascending digits. I think the static row is not usually used for that. Fyunck(click) (talk) 00:03, 4 June 2024 (UTC)

Where in MoS? I never found it. From my research, right aligned is recommended so the place values are vertically aligned making it easier to scan and compare numbers, no matter the length or size. It's a matter of making it more readable, no matter how minor the improvement. Also, most spreadsheet apps right align numbers by default. As mentioned above, if the entire ranking is one digit long (1-9), then other alignments can be used without affecting the readability. At that point, it's just preference. You indicated that right is "usually best" and "preferred". That remains my preference. Jroberson108 (talk) 14:15, 4 June 2024 (UTC)

I couldn't find it either. Where in MOS does it say right is usually best for numbers since they align for addition and decimal points? Qwerty284651 (talk) 02:19, 5 June 2024 (UTC)

Not sure where I read it in MOS. It could have been in a talk page discussion under MOS. When I originally saw this moved to center I checked out many discussions here. The Advanced Table Help page says right. There was a discussion at MOS where it was brought up and again "right" was verified. I'd have to go through my history to check out all the pages I looked at. Fyunck(click) (talk) 04:14, 5 June 2024 (UTC)

The advanced table help page gives an example, a guide on how to align a table to the right not a MOS rule. This right-alignment for numbers I don't know where editors got it from. I always align digits center, that's a no brainer for me. Qwerty284651 (talk) 10:18, 5 June 2024 (UTC)

It's a standard practice outside of wikipedia. For some here, right alignment is a no-brainer. For some left alignment is a no-brainer. Maybe it depends on what your used to. For me I usually align left for all as it was what I was taught. I was also taught that when you are tabulating numbers, you align them right. And MOS is our guideline, not our rule. Policy is our rules. Fyunck(click) (talk) 20:07, 5 June 2024 (UTC)

I agree with what is being said. I am in the minority of favoring center alignment. Tabulating and aligning I see is very subjective...to each editor/user their own. Qwerty284651 (talk) 20:40, 5 June 2024 (UTC)

I think in most of the world, if you have a line-up of numbers that is being added, it is always right-aligned. The digits must align if possible. The ones, the tens, the hundreds columns must align. That's probably where it comes from to right align all number columns. When you have a column of numbers that isn't being added up at the end, it isn't as important that the digits align, so that is where it becomes subjective as to use. Then, as someone mentioned above, when you have tiny numbers and large numbers, scanning is easier when they are aligned one way or the other. It's when we have perfectly ascending numbers 1-2 digits long (rarely 1-3 digits long), it becomes as you said even more subjective of right/left/center. Fyunck(click) (talk) 21:20, 5 June 2024 (UTC)

Is static row accessible?

Do screen readers detect static row as a row header or do they jump straight into the data cell in column 2? I am asking whether it is accessible. Does it require an "id=...". Otherwise, I can just use regular data cells. Qwerty284651 (talk) 10:45, 5 June 2024 (UTC)

Per the #Remove the 3rd parameter discussion above, Graham87 mentioned accessibility questions should be asked at Wikipedia talk:Manual of Style/Accessibility. Since the cells and content are added purely by CSS, you won't be able to add the "id" and "headers" attributes. Also note that the "cells" are added before the table rows, not in them. Usually those attributes are added if the headers are complex. See Wikipedia:Manual of Style/Accessibility/Data tables tutorial#Complex tables. Jroberson108 (talk) 13:47, 5 June 2024 (UTC)

Thanks. Qwerty284651 (talk) 16:34, 5 June 2024 (UTC)

See further discussion here:

• Wikipedia talk:Manual of Style/Accessibility#Is Template:static row numbers accessible?

--Timeshifter (talk) 02:43, 8 June 2024 (UTC)

Number row without border and white background

The most recent update of the template now displays {{static row numbers}} as a column without borders and with a white background. Can you fix this? Qwerty284651 (talk) 02:10, 4 July 2024 (UTC)

The change causes issues on vector legacy, monobook, and timeless. I didn't see where the background was white though. Reverted the change. TheDJ, can you give more info on testing night mode? Are you fixing for the "Dark mode toggle" or "Core styling" gadget or something else? Jroberson108 (talk) 02:49, 4 July 2024 (UTC)

Looks like a skin specific problem indeed. It seems that not all skins have all CSS tokens yet. As such, whenever you use a variable, we should probably define a fallback value. I did so for this border in https://wiki.riteme.site/w/index.php?title=Template:Static_row_numbers/sandbox/styles.css&diff=prev&oldid=1232569160 We probably should add fallbacks to the other variables as well honestly. —TheDJ (talk • contribs) 12:09, 4 July 2024 (UTC)

As Recommendations_for_night_mode_compatibility_on_Wikimedia_wikis#Use_CSS_variables_or_CSS_design_tokens_with_fallback_for_background_and_text_where_possible details: " When using the CSS variables for Codex design tokens, always provide a fallback value for skins where CSS variables are not supported." —TheDJ (talk • contribs) 12:30, 4 July 2024 (UTC)

Any fixes I'm doing are with the core styling in mind btw. I personally see the dark gadget as something that will be deprecated soon as it is not universal across the wikis, has bad performance and color shifting. —TheDJ (talk • contribs) 12:12, 4 July 2024 (UTC)

As there was no further feedback on the sandbox changes, I deployed them. —TheDJ (talk • contribs) 13:38, 9 July 2024 (UTC)