Why sorttable doesn’t handle colspanned rows

My sorttable JavaScript library (for, er, sorting HTML tables) doesn’t handle tables with colspanned rows in them. I get asked about this a lot. So, a note.

Sorttable doesn’t handle colspanned cells because how to do so is remarkably author-specific. That is: for a given table, I know how to create a simple solution to handle it, but I don’t know how to make something which works for everyone, because different authors want different things. Take the table below as an example:

[raw]

col 1 col 2 col 3


aaa 111 ABCDEFGHIJKLMN bbb 222 DEFGHIJKLMNOPQ cccccccccccccc GHIJKLMNOPQRST ddd 444 JKLMNOPQRSTUVW

[/raw]

Now, the problems with this table are in two flavours.

The first is: you will note that every row has column 3 and column 4 colspanned. So, sorting the table by column 3 should obviously sort by the content in cell 3 in each row. The question is: what should sorting on column 4 do? Some authors expect it to sort exactly the same as clicking column 3’s header should do. Other authors expect column 4’s header to not be clickable at all. Sorttable can’t know which to do, and I am extremely loath to add configuration options to sorttable to allow the author to choose; sorttable’s overriding goal is to work without configuration by working out the best thing to do, and I’d rather not offer a feature than offer one and insist that it be configured in order to work.

The second problem is with row 3, which colspans over columns 1 and 2 even though other rows do not. This is similar to the first problem, but “what is the logical thing to do that everyone will expect” in this situation is even less obvious, I think.

One solution that I hear a lot is: pretend that a colspanned cell exists in both columns. That is, pretend the above table actually looks like this:

[raw]

col 1 col 2 col 3 col 4


aaa 111 ABCDE ABCDE… bbb 222 DEFGHDEFGH… cccccc… cccccc… GHIJKGHIJK… ddd 444 JKLMNJKLMN

[/raw]

…and then someone says “but I want that thing you mentioned above, where a column is unsortable if there aren’t any cells actually in it”, and that idea goes away. Or they’ve got the “this one row has a colspan in it” (as in “problem 2” above), and what they expect is that the “second” cell in that row is treated as if it contained emptiness. All of these are real examples that I’ve discussed with users of the sorttable library over the last six or so years.

So, that’s why sorttable doesn’t handle colspans natively. As you can see, if the author knows how they want to handle these problems, then implementing a solution is easy; the problem is that sorttable doesn’t know.