[whatwg] Sortable Tables

Wed Sep 11 12:47:29 PDT 2013

On Fri, 19 Jul 2013, Stuart Langridge wrote:
> On Thu, Jul 18, 2013 at 11:48 PM, Ian Hickson <ian at hixie.ch> wrote:
> > > 
> > > but <time> is more of a problem if you have multiple things in one 
> > > cell. For example, one semi-common pattern is to put some data and 
> > > an input type=checkbox in a single cell, like <td>Wed 7th November, 
> > > 10.00am GMT <input type="checkbox" name="whatever"></td>
> >
> > Why can't the checkbox be in a separate cell?
> 
> I'm not saying that this is the way I do it: I'm saying this is what 
> authors are currently doing. If the checkboxes need to be in a separate 
> cell, then OK, but we'd need to explain that that's the case: that is, 
> the answer to "how do I sort a table by a column containing both data 
> and a checkbox" is "you can't. Put the checkboxes in a separate column." 

Yeah, fair enough. Hmm.

So what should we do? Allow there to be multiple elements in the cell, but 
if we see a <time>/<meter>/<progress>/<data>, ignore all the others for 
sorting? Just look at the first element and if it's one of those, ignore 
all the others for sorting? I fear situations where people have two <time> 
elements and want them sorting by one then the other, or something. We 
could also have a way to say that certain elements are ignored... ignore 
all <input> and <img> elements? Ignore all elements with a new ignore-me- 
when-sorting="" attribute?

I agree we should support the case you give.

> Indeed, the objection to wrapping the whole cell content in <time> 
> applies to any cell which contains a time *and something else*: for 
> example, <td>Wed 7th November, 10.00am GMT <img src="morning.png"></td> 
> where the image displays a nice picture of the sun so you can see that 
> it's morning, but is only debatably part of the actual time itself.

I'd feel much more comfortable saying the sun was part of the time than 
about the checkbox being part of the time. :-)

> (And if you put it in a separate column, then there'll be a cell border 
> between the time and the icon.)

That can be fixed with CSS, of course.

> > > Using <data> to wrap the whole cell is OK, but using <time> to wrap 
> > > a bunch of non-time content isn't, really. In this situation would 
> > > you recommend <td><data value="2012-11-07T10:00Z"><time 
> > > datetime="2012-11-07T10:00Z">Wed 7th November, 10.00am 
> > > GMT</time></data></td> which seems rather redundant to me?
> >
> > I would recommend using two cells, but you could do that too. It would 
> > mean the keys were compared as strings, though, rather than as 
> > datetimes. Things wouldn't work if you mixed <data> and <time> 
> > elements with those values (e.g. if some cells didn't have checkboxes 
> > and so you used just <time> in some cases), since strings sort after 
> > times.
> 
> erm. Why is the sort clever about datetimes?

Time zones, knowing that "1:01" comes before "01:02", knowing that "P1D" 
comes before "25h", knowing that "1000-01-01" comes before "01010-10-10", 
knowing that "-01:00" comes before "Z" comes before "+01:00", knowing 
that 2013-W37 comes before 2013-10-11 but after 2013-10-09, etc.

> Specifically, in order to specify a datetime attribute on a time 
> element, you have to specify it as a string, and those strings sort 
> correctly in order with other datetime strings.

Not necessarily. Leading zeros are a problem for times, local-dates- 
and-times, and yearless dates, and all the other time formats have crazy 
stuff like time zones, multiple valid formats, etc. Also, the spec 
supports mixing different formats like week dates and years with date-and- 
time formats.

> > > Maybe pass a cloneNode of each TD?
> >
> > Too expensive (what if one of the nodes is a 24 MB image, or a 
> > plugin?).
> 
> But the cloned node isn't inserted into the document, right? Surely no 
> rendering engine is going to fully instantiate a 24MB image that's not 
> even in the document?

An <img> element is instantiated when created, regardless of whether it's 
in a document or not. That's how you can do preloading of images for 
rollovers, if you're stuck in the 90s. :-)

> > > Or have the sorter work out the sortable *value* of the field (from 
> > > the content, or the <data value> wrapper) and then pass the values, 
> > > not the actual cells? Then the comparator can't destroy anything.
> >
> > It seems to me like that doesn't give you anything that you couldn't 
> > do by just setting the keys manually on the table before the sort 
> > happens (which you can do easily onsort="" in the current model).
> 
> Big difference: setting the keys manually onsort is indeed something 
> that the author can do. But calculating the sortable value of the cell 
> (either from an explicitly set key, or from the cell content) is 
> something that the *browser* can do: that is, it can be part of the 
> spec. So then you're never in danger from dangerous comparators, because 
> the sort engine algorithm is: (1) for each cell in the column, calculate 
> its sortable value and make a list of [sortable value, reference to 
> cell], (2) sort that list, and for each comparison during sorting pass 
> the two sortable values you want to compare, but *not* the cell 
> references, to the comparator, (3) now you have a sorted list; shuffle 
> the actual table rows into the order of the list. This is what my 
> sorttable script does, and for exactly the reasons that you outline; 
> that a sort comparator function doesn't get passed the actual TDs, just 
> their content.

If you call script at all, it can mess up the table, whether or not you 
hand it a reference to the table.

But my point above was: what's the difference between allowing authors to 
set the comparator function, and letting authors assign the sortable value 
when there's a known comparator function? Both get you the same effect, 
surely. The advantage is one doesn't need to involve calling script while 
the table is being sorted.

> > > Left-hand header columns (although as noted this is sorta-kinda 
> > > presentational and should be done with tr::before, but authors will 
> > > do it in the HTML for backwards-compatiblity if nothing else).
> >
> > Not sure I follow that one.
> 
> I, Mr Author, have a table on my page, and that table has row numbers, 
> explicitly in the HTML as the first column. (<tr><td>1</td><td>...</tr>) 
> I wrote the page 5 years ago, and half my users are still, depressingly, 
> on IE6. The other half are all running Chrome Canary, usefully. So this 
> sorting stuff arrives and I think: I'd like this table to be sortable. 
> So I bang the sort stuff in, knowing full well that the IE6 people don't 
> get to sort the table, and that's fine (progressive enhancement, wot?), 
> and the Chrome people say "oh, man, the row numbers get jumbled!" and I 
> say "ah, you're quite right", and remove them from the HTML to be 
> replaced with CSS tr::before { content: index(row) } or something. And 
> then the IE6 people say: we don't have any row numbers any more! I am 
> not sure how this is reconcilable. Either older browsers don't get row 
> numbers, or newer ones get them jumbled...

I don't know how to fix this in a world where we're sorting groups of 
rows. I mean, if group #1 is a single row, and group #2 has two rows, and 
group #3 has three rows but its first cell spans all three, what do you do 
when the order is changed to #3-#1-#2, if the first column is one of these 
"keep the numbers consistent" columns?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'