You have to use the shift-key, see the documentation on https://meta.wikimedia.org/wiki/Help:Sorting#Secondary_sortkey.

Thanks Michael.

That makes this request RESOLVED WORKSFORME, I guess?

(In reply to Dave Yost from comment #0)

Instead you get a sort with B as the major comparison, and A is ordered
randomly, because the sort algorithm used is unstable.

Do not use unstable sort for user interfaces, ever. Your favorite algorithm
might, /might/, be a tiny bit faster, but that feature is completely blotted
out by the importance of usability.

This is probably not true. The sorting algorithm (which, by the way, is simply Array.prototype.sort) is supposed to be stable (the code even has comments about this), but it is stable in relation to the original table ordering and not the "previous" table ordering.

(If you have tested this and it isn't stable, then that's a bug.)

Click to sort ascending on column 1.
-> table resorted ordered by column 1
Click to sort ascending on column 2.
-> table resorted ordered by column 2
-> column 1 is no longer sorted

You're actually describing a feature, and a change in current behavior, that you would like to see. (The original bug summary was incorrect, Andre fixed it.)

I agree it would be useful in some cases, but sorting by the original order is also useful in some cases (e.g. when one of the table's columns is the row's ordinal number).

Do you think that replacing the current behavior with this one would be better in the general case, especially if there's the workaround Michael described?

Dave wrote:

If it's useful to re-sort the table in the original order, then provide a column numbered by the original order. (This should probably be standard practice) One click on that column title and boom. You have reset the sort order. That feature is easily discoverable and logical.

I claim that the feature I am advocating is by far the most useful sorting facility. It enables filtering by sorting. If you want to find all the table rows that have the three features you want out of a dozen features in as many columns, you click on those three column headings, and you will have clumped together the rows that have what you want. I didn't make this up. I've used the feature elsewhere. I just searched and couldn't find any user testing of this, unfortunately.

Hiding this feature behind a Shift key written about far away in a mass of documentation means that effectively 0% of the population will be able to sort tables in this way.

Dave wrote:

BTW, the URL example I gave, with its red-yellow-green table cell values, is a classic example where the table is ready to go for filtering by sorting, if the stable sort feature were in place.
http://en.wikipedia.org/wiki/Comparison_of_HTML_editors#Editor_features

You should be able to simply click on the columns you care about so that the green comes to the top on all 3 columns. BTW, shift click doesn't work for this.

Whatever it is doing now, with or without the shift key, I can't see any usefulness to clicking column headings in any particular order.

Per T33255, the ability to sort by multiple columns has been implemented. However it is not enabled by default (thus creating the predictable behaviour that a sort instruction always creates the same result, regardless of buttons you pressed previously).

It is currently triggered via the Shift key. See T43926 for the discovery problem.

If we come to an agreement that it should use secondary sort by default, then that would solve T43926 as well.

I wouldn't recommend making secondary sort the default; that is not expected behaviour.
It doesn't look like that's the intention of the original request either. I assume it was a sorting stability issue/bug back then (and with that, I guess this ticket can be closed).

Note that the task description doesn't describe the exact same behaviour as the shift-click method of secondary sorting. To achieve the same final sort order:

• Sort on column B, then shift-click on column A: the primary sortkey is column B, the secondary sortkey is column A
• Sort on column A, then click on column B: the primary sortkey is column B, and when the sorting algorithm is stable, the secondary sortkey should (silently) be column A -- described by Dave as the expected but not observed behaviour

Both ways are perfectly fine to achieve the same final sort order, or in other words: after a first sort, click or shift-click on another column determines if that column will be the primary or secondary sortkey, respectively.