In 1.18's tablesorter only headers can mark if a row or column should not be sorted. You cannot use an individual cell to mark sortability. Wether or not that is desirable...

To repeat a header, actual thead's should be used from 1.18 on btw..

There also seems to be an issue with footers btw.

http://test2.wikipedia.org/wiki/User:TheDJ/tables#Excluding_the_last_row_from_sorting

Adding Krinkle since Trevor says he did a lot of this rewriting.

This is NOT fixed, I just lost track of my tabs.

(In reply to comment #1)

In 1.18's tablesorter only headers can mark if a row or column should not be
sorted. You cannot use an individual cell to mark sortability. Wether or not
that is desirable...

To repeat a header, actual thead's should be used from 1.18 on btw..

A table can only contain zero or one thead -- you can't add a second one later on in the table. (You can however have multiple tbody sections.)

Note also that unless you make an explicit thead, it looks like it's the jquery.tablesorter code that creates a thead out of the first row(s) containing only th cells. (in emulateTHead function)

(In reply to comment #2)

There also seems to be an issue with footers btw.

http://test2.wikipedia.org/wiki/User:TheDJ/tables#Excluding_the_last_row_from_sorting

The 'footer' row there is just a regular row in the tbody; it's not broken out to a tfoot like the row(s) of ths at the beginning. Though it would probably not be hard to do much the same as emulateTHead() for rows at the end, this may not work for header rows in the middle of a table... I guess you could break them out into multiple <tbody>s but I'm not sure what effect that would actually have on how the table looks and behaves.

Bumping down to "high" priority now. This won't be a 1.18 blocker (at least today). This seems like kind of a crazy misfeature to me, but I don't know how much people are counting on it or how much it really enhances usability on pages that use it.

The "unsortable" class is used a fair amount on most wikis. However from what I understand it works fine when added to the heading (which is where it is in most cases).

It apparently used to work in the middle of a table as well, and no longer does.

I wasn't aware of this working at all, but since it does I think we should WONTFIX this (unless it's easy to fix). It was an undocumented feature that might very well be a bug in the original code.

(In reply to comment #7)

I wasn't aware of this working at all, but since it does I think we should
WONTFIX this (unless it's easy to fix). It was an undocumented feature that
might very well be a bug in the original code.

Bugs that people rely on become features they expect. I'd like to get a measure of how widely this use of the "unsortable" class is before we say WONTFIX.

I also see reports of multiple tables being 'broken' on the nl.wikipedia.

For instance this one:
http://nl.wikipedia.org/wiki/Brussels_Airlines#Passagiersaantallen

I think we should auto generate a tfoot, just as we do for thead.

Added tfoot emulation in r98669

tagging bugs for Marcus to look at

(In reply to comment #9)

I think we should auto generate a tfoot, just as we do for thead.

I'm confused: how would that fix the "unsortable" problem.

Let's try to get this figured out by the time we branch 1.19, but let's also not hold up 1.18 for this.

Think this is fixed. See http://en.wikipedia.beta.wmflabs.org/wiki/Tables

No, my example still doesn't work, see http://en.wikipedia.beta.wmflabs.org/wiki/User:Schnark

In 1.17 and earlier the bold line was always the third, no matter how you sorted.

Only unsortable rows at the end of a table work again. If you think the feature of having unsortable rows in the middle of a table should just be removed, then close this bug as WONTFIX, and I won't protest, since I can't think of a use-case.

(In reply to comment #15)

In 1.17 and earlier the bold line was always the third, no matter how you
sorted.

Ok, got it. CSS class "unsortable" isn't supported even though the unsortable footer lines is now supported. I'll ping robla about this.

*sigh*...kicking this down the road again. I've bumped this to high priority, but since it's not a regression, it's hard to justify stopping 1.19 until we fix this.

(mass change)

• 1.18.0 and 1.19.0 have been released already.
• Moving open bugs targeted for 1.18.0 or 1.19.0 to Mysterious future.
• Please re-target them to 1.19.x or 1.20.0 if needed.

This change took place about 20 months ago so whoever still uses the "unsortable" CSS class likely has realized that it's broken and worked around it somehow (or just removed it), plus there weren't many indicators that many users were affected by this change, so I'm decreasing priority nowadays.

timjones86 wrote:

We haven't been able to find a workaround.

The unsortable CSS class was REALLY useful for long sortable tables, as it could provide section breakers that divided the table up at suitable points, while at the same time retaining its sorting capability. Without it, we now have either long, unwieldy tables (as in http://en.wikipedia.org/wiki/List_of_1990s_UK_Albums_Chart_number_ones), or tables with headers that jump all over the place when they're sorted (as in http://en.wikipedia.org/wiki/List_of_1990s_UK_Singles_Chart_number_ones).

I don't really know anything about coding or CSS, but, if it's at all possible, please, please bring this function back.

Change 74270 had a related patch set uploaded by TheDJ:
TableSorter: Add option to mark rows as unsortable

https://gerrit.wikimedia.org/r/74270

Tim, I think this would be much better solved with fixed headings (bug 40763). Do you agree?

timjones86 wrote:

Assuming that fixed/floating table headers would be able to span over several rows, then, yeah, I'd agree that that sounds like a decent fix to me.

Change 74270 abandoned by TheDJ:
TableSorter: Add option to mark rows as unsortable

Reason:
abandoning, since this seems undesired.

https://gerrit.wikimedia.org/r/74270