Help talk:Sortable tables

Skip to table of contents

The main table help talk page is Help talk:Table, and you may get a more rapid response there.

This is the talk page for discussing improvements to the Sortable tables page.

Put new text under old text. Click here to start a new topic. New to Wikipedia? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed

Archives (index): 1, 2, 3, 4, 5Auto-archiving period: 12 months

This help page does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Wikipedia Help Low‑importance This page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the Help Menu or Help Directory. Or ask for help on your talk page and a volunteer will visit you there. Low This page has been rated as Low-importance on the project's importance scale.

table, sorting only one column proposition

Let's say I have a table with 5 columns. I want only one column to be sortable (others are unnecessary). To do that it seems the only way is to make table class sortable and then add class=unsortable to other 4 columns. I think it would be good to make it possible to make a column sortable with class=sortable independent of table class. It doesn't have to be 1 column, it could be 2 columns in 5 column table. Setenzatsu.2 (talk) 14:46, 31 March 2025 (UTC)[reply]

@Setenzatsu.2: Jroberson108 may have some ideas on whether this is feasible. I think it would be confusing if people start seeing class=sortable in different places in tables. --Timeshifter (talk) 11:36, 5 April 2025 (UTC)[reply]

@Setenzatsu.2 and Timeshifter: Highly unfeasible. Sorting is not implemented through a template that might be easy to manage, but instead through the backend with highly vetted changes geared towards optimal performace. A class has to be added to the table regardless. Changing the default behavior of the table's "sortable" class from sortable to unsortable would not only be less implicit, but is not optimal since most if not all columns in the majority of the uses are sortable. In addition, the change is not backwards compatible and all the current uses would have to be modified by adding sortable classes to columns and removing the now obsolete unsortable classes. Jroberson108 (talk) 16:44, 5 April 2025 (UTC)[reply]

I don't think Setenzatsu.2 asked for it to replace the current usage, but to supplement it. Gonnym (talk) 09:33, 6 April 2025 (UTC)[reply]

The table class makes all columns sortable with an optional column class to make specific columns unsortable. Wanting it so the table class does not make all columns sortable with an optional column class to make them sortable changes the current usage to something opposite. Jroberson108 (talk) 04:07, 7 April 2025 (UTC)[reply]

When a non-technical person asks a code-related request you shouldn't get too hang on the specific code name they used. Using a new and different class name makes it so there isn't a conflict. Gonnym (talk) 08:11, 7 April 2025 (UTC)[reply]

I didn't mention anything about code name or conflicting class names. Jroberson108 (talk) 09:58, 7 April 2025 (UTC)[reply]

@Setenzatsu.2, Gonnym, and Jroberson108:. I guess something like class=sort could be used for single-column use. But for it to be used without a template would require modifying the backend code. That would require a feature request at Phabricator. --Timeshifter (talk) 14:01, 7 April 2025 (UTC)[reply]

The problem is that the table class is what is used to add the ability to sort columns by moving rows, applying styling, add sorting to column headers, collapsing rowspans after sorting, etc. Regardless of the new column's class name, it is already sortable because of the table class, therefore redundant unless you change it so the columns are not sortable from the table class, which creates issues with the current usage. The second issue is that they optimize the code due to its sitewide usage and are highly unlikely to add extra or change it to reproduce something that is already possible with the current classes. But you are welcome to ask. Jroberson108 (talk) 14:57, 7 April 2025 (UTC)[reply]

Sounds like it would be a nightmare to code. Especially when the wikitext for a table has both class=sortable and class=sort. And that would happen often as different editors work on a table. --Timeshifter (talk) 15:47, 7 April 2025 (UTC)[reply]

Wiki syntax is not optimized. That should be a priority as is the code optimization. One shouldn't be more important than the other. If I have a table with 9 columns, and only 1 (or 2 or 3) makes sense to be sortable and I have to put 8 class=unsortable attributes - that's not optimized. I haven't expressed myself clearly in my proposition. As Gonnym said I didn't mean to replace usage, but to supplement it - that doesn't mean the change how class works is neccesary. Now we have table of sortable class and that is fine as it is. Another (sub)class could be implemented let's say "wikitable sortable-specific". It could be done that in the backend there is a translation layer to turn it into "wikitable sortable". "sortable-specific" would allow to point out specific columns to be sortable and other columns would be unsortable by default. It would be used when 50+% of columns is unsortable. Translation layer would just turn "sortable-specific" into "sortable" by adding attribute unsortable to non-specified columns and applying sortable to other columns, in the backend (and that's important). That should be less than 30 lines of code. Just a pseudoclass and translation layer. But it would optimize wiki syntax (from editors' perpective) and save some KBs.Setenzatsu.2 (talk) 21:27, 25 April 2025 (UTC)[reply]

Wrong sorting of fractional numbers

Fract	Bazzz	notes
0.001297	1.5	- very small fractions somehow break sorting
0.00121	0.0
4.422	0.35
3.263	8.0
3.7	8.4	- asterisk somehow interferes with sorting
3.8*	8.5*

In the table to the right if you put very small fractional number in first 5 rows and add asterisk somewhere, it breaks sorting.

Examples:

• Table of specific heat capacities: the article's table values under Isobaric volumetric heat capacity get sorted improperly

AXONOV (talk) ⚑ 09:47, 1 May 2025 (UTC)[reply]

@Alexander Davronov:

data-sort-type=number is a quick fix:

! data-sort-type=number | Fract 
! data-sort-type=number | Bazzz 

Fract	Bazzz
0.001297	1.5
0.00121	0.0
4.422	0.35
3.263	8.0
3.7*	8.4*

The very small numbers don't seem to be a problem if I remove the asterisks, or remove the asterisks from the first 5 cells in a column. I added a row, so there are 6 data rows in this table. And I moved the asterisks to the 6th row:

Fract	Bazzz
0.001297	1.5
0.00121	0.0
4.422	0.35
3.263	8.0
3.7	8.4
3.8*	8.5*

--Timeshifter (talk) 11:15, 1 May 2025 (UTC)[reply]

Yeah, that's what I did. Somehow that bug puzzled folks for 3 years in the article I've linked above. I suggest we put the case into Numerical sorting problems subsection. AXONOV (talk) ⚑ 18:44, 1 May 2025 (UTC)[reply]

I added: "Asterisks (*) in the first 5 cells break numerical sorting."

Feel free to add more info to the help page. --Timeshifter (talk) 21:15, 1 May 2025 (UTC)[reply]

Thanks. AXONOV (talk) ⚑ 21:29, 1 May 2025 (UTC)[reply]

Tables are not sortable in mobile app

There's no information about the fact that tables are not sortable in the mobile app and why. Akira 2340 (talk) 16:07, 20 August 2025 (UTC)[reply]

Jroberson108 may be able to help here. --Timeshifter (talk) 19:11, 20 August 2025 (UTC)[reply]

@Akira 2340 and Timeshifter: See Help talk:Sortable tables/Archive 4#Mobile Sorting. Jroberson108 (talk) 21:29, 20 August 2025 (UTC)[reply]

Thanks Jroberson108. I added a note to the top of the help page:

Note: Tables are sortable in mobile browsers, but not in the mobile app. See phab:T181452.

--Timeshifter (talk) 22:01, 20 August 2025 (UTC)[reply]

Sorting multiple columns at once

I found an article that has two adjacent columns that sort identically by necessity. Is it possible to have an elegant way of joining the two columns up at the top with a single set of sort arrows? Not important, but it could be nice.

https://en.wikipedia.org/wiki/Midwestern_United_States#Major_metropolitan_areas

Misha Vargas (talk) 22:30, 27 October 2025 (UTC)[reply]

I moved the MSA and State(s) columns next to each other. I think your only option is to put them in the same column. Titled: MSA and State(s). MSA = Metropolitan Statistical Area. I put this in the caption too.

Jroberson108. Do you have any other ideas? --Timeshifter (talk) 23:08, 27 October 2025 (UTC)[reply]

Misha Vargas. Forgot to ping you. --Timeshifter (talk) 23:10, 27 October 2025 (UTC)[reply]

@Misha Vargas: Do you mean something like this where the column header spans two columns? It sorts according to the MSA data, not the states. It's the same as keeping the column headers separate and making the State(s) column unsortable.

Metropolitan Statistical Areas (MSA) ranked by population size

Rank (Mid­west)	Rank (USA)	MSA and State(s)		Population­
1	3	Chicago	Illinois Indiana Wisconsin	9,449,351
2	14	Detroit	Michigan	4,392,041
3	16	Twin Cities	Minnesota Wisconsin	3,690,261
4	21	St. Louis	Missouri Illinois	2,820,253

Jroberson108 (talk) 23:21, 27 October 2025 (UTC)[reply]

I was actually talking about the far left side of the table, sorry. The ranks (by population) are always going to be in the same exact order whether you click "Rank (Midwest)" or "Rank (USA)".

I'm not sure there's a way to do this that looks nice. It's fine enough, I suppose. —Misha Vargas (talk) 23:31, 27 October 2025 (UTC)[reply]

I wasn't thinking clearly earlier. For some reason I thought the MSA and the State(s) in a row would separate during sorting. Not true. The individual rows stay exactly the same during sorting.

So I don't really see the need now for combining columns, or using colspan. The reader has more sorting options if each column can be sorted individually. Nothing unsortable except the image column. I don't see a purpose in keeping it sortable.

It is useful to keep the 2 rank columns separately sortable. People may want to know how MSAs rank in the Midwest versus the USA. --Timeshifter (talk) 00:02, 29 October 2025 (UTC)[reply]

That last bit...doesn't really make sense. You can click on either of the two columns; try it. They don't do anything different. You can go back and forth between them. Nothing changes. Anyways, don't worry about it. —Misha Vargas (talk) 00:11, 29 October 2025 (UTC)[reply]

But people don't know that ahead of time. The only way to know for sure is to try it. So they both need to be sortable. --Timeshifter (talk) 11:53, 29 October 2025 (UTC)[reply]

"regarded as zero if it is empty" for number sort type

Help:Sortable tables#Default data type of a column → number says that [the string] is regarded as zero if it is empty. Yet from what I observed, for data-sort-type="number" empty string appears to be −∞, like other non-numeric strings. Also I see that mediawikiwiki:Help:Sortable tables#Controlling sorting and display mentions An empty cell sorts as "-Infinity". May I know if I understand the documents correctly, or if the behaviour has changed?

Demo sort empty string by number

Default data sort type	data-sort-type="number"	data-sort-type="text"
1	1	1
-1	-1	-1
2	2	2
-2	-2	-2
0	0	0
text	text	text
,	,	,
(data-sort-value="")	(data-sort-value="")	(data-sort-value="")
more text	more text	more text
-0.5	-0.5	-0.5

Thanks! — Peterwhy (talk) 06:50, 26 November 2025 (UTC)[reply]

I added a line break in one of the blank cells so that the row of blank cells is more visible.

I haven't studied this, and probably won't have time. Feel free to correct anything on the help page. Others are watching for mistakes too. So don't hesitate. Please use simple English on the help page. Cause it is a help page!

-∞ baffled me on the help page in the "number" subsection here:

Help:Sortable tables#Default data type of a column

Jroberson108 may have some knowledge about this. I am baffled by how some of the sorting works.

--Timeshifter (talk) 23:03, 26 November 2025 (UTC)[reply]

@Peterwhy and Timeshifter: As far as I know, if data-sort-type is "text", then they are sorted by the ASCII values. When data-sort-type is "number", then the number cells are sorted numerically and non-numbers are sorted as ASCII, but non-numbers appear above the numbers as if they were "-Infinity" as a comparison to numbers. Jroberson108 (talk) 00:00, 27 November 2025 (UTC)[reply]

Thank you both for checking. I am new to the deeper behaviour of sortable, so I am not sure enough to edit this help page. But if I may (and if the −∞ behaviour is correct), then I am proposing to remove it is regarded as zero if it is empty; and change its following text to

in other cases (including if the string is empty) (parseFloat returns NaN), the element is positioned like -∞.

under Help:Sortable tables#Default data type of a column. — Peterwhy (talk) 01:32, 27 November 2025 (UTC)[reply]

@Peterwhy and Timeshifter: Sounds good. I would recommend more clarity on the sorting of non-numbers though. Maybe this or something cleaner? "in non-number cases, the order is ASCII and positioned like -∞ in relation to the sorted numbers." Jroberson108 (talk) 01:50, 27 November 2025 (UTC)[reply]

@Jroberson108: I am not sure about your suggestion on the sorting of non-numbers. Was that still about Help:Sortable tables#Default data type of a column → number, or was that about ... → string (slightly below number), or was that about Help:Sortable tables#data-sort-type=text section (above number)?

If the quote was about data-sort-type="number", then I don't see how ASCII is considered. To me, all the non-number strings appear to be equal (to -∞) and not reordered relatively among themselves. — Peterwhy (talk) 02:29, 27 November 2025 (UTC)[reply]

@Peterwhy: It was for numbers. Seems like it doesn't sort non-numbers by ASCII, but rather keeps them in the same order prior to sorting? My confusion came from sorting by the text column first, then number, which sorts them differently than just doing number only. Jroberson108 (talk) 06:59, 27 November 2025 (UTC)[reply]

@Jroberson108 and Timeshifter: Thanks all for the input. I made the change to Help:Sortable tables#Default data type of a column according to my proposal above. — Peterwhy (talk) 06:00, 28 November 2025 (UTC)[reply]

Exceeding double precision

Since numerical data sort values are stored in double-precision floating-point format, I had the idea of writing a section about limitations of double precision. In particular, I found that passing a numeric string that parses as +∞ would allow numeric sorting at positive infinity. –LaundryPizza03 (dc̄) 06:13, 20 January 2026 (UTC)[reply]

Okay, I have an example now (based on Isotopes of bromine). I don't think we have a section on tables with mixed units yet, and the final draft might use a different subset of the table.

Isotopes of bromine

{| class="wikitable sortable" |+ Isotopes of bromine |- ! Isotope ! Half-life |- | <sup>75</sup>Br | data-sort-value = 5802 | 96.7&nbsp;min <!--Sorted in seconds for compatibility of units--> |- | <sup>76</sup>Br | data-sort-value = 58320 | 16.2&nbsp;h |- | <sup>77</sup>Br | data-sort-value = 205344 | 57.04&nbsp;h |- | <sup>78</sup>Br | data-sort-value = 387 | 6.45&nbsp;min |- | <sup>79</sup>Br | data-sort-value = 1e309 | stable <!--Exceeds upper limit of double precision--> |- | <sup>80</sup>Br | data-sort-value = 1060.8 | 17.68&nbsp;min |- | <sup>80m</sup>Br | data-sort-value = 15913.8 | 4.4205&nbsp;h |- | <sup>81</sup>Br | data-sort-value = 1e309 | stable <!--Exceeds upper limit of double precision--> |- | <sup>82</sup>Br | data-sort-value = 127015.2 | 35.282&nbsp;h |- | <sup>83</sup>Br | data-sort-value = 8546.4 | 2.374&nbsp;h |} Isotopes of bromine Isotope Half-life ^75Br 96.7 min ^76Br 16.2 h ^77Br 57.04 h ^78Br 6.45 min ^79Br stable ^80Br 17.68 min ^80mBr 4.4205 h ^81Br stable ^82Br 35.282 h ^83Br 2.374 h

–LaundryPizza03 (dc̄) 06:50, 20 January 2026 (UTC)[reply]