[whatwg] Sortable Tables

[Christoph Päper]

Ian Hickson (2012-11-06):
> On Thu, 1 Jul 2010, Christoph Päper wrote:
>> 
>> For starters, only rows inside ‘tbody’s shall be reordered.

That means every row groupp shall be sorted independently from others, while ‘thead’ and ‘tfoot’ remain unsorted, possibly bearing sort widgets.

>> Not every table has content that makes sense to be sorted in a different order.
>> So sortable tables should be marked as such.

We shall use opt-in, obviously. It’s not strictly necessary to mark ‘table’ as sortable, if at least one of its rows is marked as such, but it would be handy for “autosort” where the author just wants to enable sorting without specifying the details.

  <table sortable collapsible>

(Table collapsing is a slightly different beast, but related. Let’s deal with that separately later, though.)

>> Note that ‘col’ and ‘colgroup’ elements are hardly supported.

But they’re essential for assigning sort properties.

  <col key=…>
  <colgroup key=…>

A ‘col’ inherits the ‘key’ from a parent ‘colgroup’, but may override it.

>> Not every column has content that makes sense to be sorted in a different order. So non-sortable columns inside sortable tables should be marked as such.

Here, I’m talking about columns that should be sorted, but not act as sort keys. See below for fixed columns.

  <col key=none>
  <col key="">

>> There are different ways to sort, eg. numeric, temporal or alphabetic 

This easily gets more complex than you wish.

  <col key=auto>       = <col key>
  <col key=numeric>    1 = 100% = 1.0 = 1e0 = 2/2 …
  <col key=text>       Ä = ä = A&#x0308; …
  <col key=date>       2012-11-06 = 2012-W45-2 …
  <col key=value>      1000 g = 1 kg = 0.001 t > 1 lb

  <col key=style>      can of worms
  <col key=class>      hardly better

The default ‘key’ is ‘auto’ for explicit columns and ‘none’ for implicit columns. 

>> and ascending or descending.

It’s probably overkill to give authors the means to specify the preferred direction. It’s certainly not sane to let them exclude one or the other.

>> Therefore columns should bear (…) what kind of content their cells have.

Authors will mess this up of course, but then it’s their fault. Let’s not overload ‘title’ or ‘abbr’.

>> Several columns may be used for sorting by some kind of priority.

This is a UI question, though.

>> The original order must be restorable.

Also mostly a UI issue, although if authors could describe how they initially sorted the data, that could also be used. They would err and lie more often than not, though.

>> Cell content may not consist of the string that should be used verbatim (…).
>> Cells should have an optional attribute indicating their sort key.

  <th value="Rolling Stones, The">The Rolling Stones
  <td value="0.454">1 lb

>> There may be columns that shall remain stable, eg. rank numbers.

  <col key=fixed>

> This is a very interesting idea.

It was in 2010 and still is.

Pitfall: ‘rowspan’ and ‘colspan’

Cells may span several rows or columns or both, and are always rectangular. Therefore, we should not sort cells! We should sort slots instead, as defined in <http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#table-model>.

A slot is uniquely identified by its row and column numbers and itself is not represented in markup, i.e. in CSS, it cannot be selected by element or other generic selectors, but a pseudo-element like ‘::slot(row,column)’ would be possible, and is as desirable as something like ‘getSlotValue(x,y)’, possibly cf. <https://www.w3.org/Bugs/Public/show_bug.cgi?id=19051>. 

Assuming current attributes and elements, a ‘td’ or ‘th’ cell covers ‘rowspan’בcolspan’ slots and each of these has the same value. The slot value is that of its cell, and dynamically changes with it. The cell value is either its content normalized to a string or, if present, the value of its ‘value’ attribute. Sorting is done by first evaluating the slot values as suggested by the ‘key’ attribute value valid for their column, and by second sorting rows using the slot values in the user selected (or default first) column as primary key accordingly. If the same column has been used for the previous sort, the order is reversed (ascending ↔ descending). If a different column has been used before, it’s used as secondary key, and so on.

Cells spanning several columns (only) will usually remain intact for normal, vertical sorting, unless an affected sort key is set to ‘fixed’ in exceptional cases. Cells spanning multiple rows in the column to be sorted by, usually remain intact, too. Other cells spanning multiple rows (and possibly columns) need to be split into slots for sorting and (optionally) should be rejoined as far as possible afterwards.

To support this, cells must be splittable!

  td     {color: green;}
  #split {color: red;}

  <tr><td>3 <td id=split colspan=2> red
  <tr><td>1
  <tr><td>2 <td> green

after sorting by the first column should look like

  <tr><td>1 <td id=split> red
  <tr><td>2 <td> green
  <tr><td>3 <td id=split> red

would if duplicate IDs were legal. The DOM tree, however, would not change! The value of the cell at position (1,1), i.e. second row and column since we count from zero, is always undefined, but the value of the slot at (1,1) changes from “red” to “green”.

Once we have splittable cells, one could imagine additions to the CSS table model and Selectors that allowed arbitrary partial repositioning of slots, think 15-puzzle. Let’s not go there yet, and not here.

User agents should not be required to sort tables that contain malformed slots, i.e. where multiple cells try to cover the same slot, e.g.:

  <table>
    <tr> <td> a <td rowspan=2> b
    <tr> <td colspan=2> c
  </table>

There may be rows that should always go to the top or the bottom of their group. This should be handled by table headers and footers in most cases, otherwise it is not covered yet.

> Is this something browser vendors would be interested in implementing?

I, for one, hope so.