Re: [whatwg] Sortable Tables
On Fri, 19 Jul 2013, Stuart Langridge wrote: On Thu, Jul 18, 2013 at 11:48 PM, Ian Hickson i...@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 tdWed 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, tdWed 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 tddata value=2012-11-07T10:00Ztime datetime=2012-11-07T10:00ZWed 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
Re: [whatwg] Sortable Tables
On Fri, 28 Dec 2012, Stuart Langridge wrote:
Sorttable also allows authors to specify alternate content for a
cell. td sorttable_customkey=11eleven/td
tddata value=11eleven/data/td
The sorttable.js solution is to specify a custom key, which
sorttable pretends was the cell content for the purposes of sorting,
so td sorttable_customkey=20121107-10Wed 7th November,
10.00am GMT/td and then the script can sort it.
tdtime datetime=2012-11-07T10:00ZWed 7th November, 10.00am
GMT/time/td
I can see using data for this, because it's deliberately semantically
meaningless (right?)
I wouldn't say it's semantically meaningless, but sure.
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
tdWed 7th November, 10.00am GMT input type=checkbox name=whatever/td
Why can't the checkbox be in a separate cell?
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
tddata value=2012-11-07T10:00Ztime datetime=2012-11-07T10:00ZWed
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 date 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.
and this, like many other things on this list, suggests that some
sort of here is the JavaScript function I want you to use to
produce sort keys for table cells in this column function is a
useful idea. Sorttable allows this, and people use it a lot.)
I tried to do this but couldn't figure out a sane way to do it. A
comparator can totally destroy the table we're sorting, and I don't
know what to do if that happens.
As in, you specify that there's a comparator function and then the
sorter passes the comparator function two TD elements for comparing,
and the comparator function looks like this?
function comparator(td1, td2) { td1.parentNode.removeChild(td1); }
Right. Or worse (e.g. moving cells around on rows that have been
compared before).
Also it totally destroys any ability to cache information per-row, which
I think would be disastrous given how much work it takes to compare rows.
On the other hand, surely I could make the same argument about any
handler, right? If you put scriptdocument.body.innerHTML +=
hahaha!/script as a child of body, browsers used to crash (because
it's an infinite loop), and the implementor response boiled down to
don't do that, at least at first.
Only at first, because it wasn't tenable. We had to eventually define what
happens, exactly.
It's hard to see how such a malicious script could get into a page
without author knowledge --
It might well be with author knowledge. More likely it's a bug in their
code.
of course, an author might include a third-party script which does this
to destroy a page, but the same third-party script could set
document.body.innerHTML to 0wned which is even more destructive of
page content.
That's not really a problem. The problem is making sure that the algorithm
is stable in the face of crazy comparators, because any lack of stability
could lead to security bugs (e.g. if you make it crash somehow, and can
use that to run arbitrary code).
It would be reasonable, I think, for the sort process to halt
uncompleted if a comparator function destroys the things it's comparing,
although perhaps your concern is that it's hard to know *whether that
happened* (since it might just reparent them to a different table or
something)?
It's hard to detect cheaply, certainly.
Maybe pass a cloneNode of each TD?
Too expensive (what if one of the nodes is a 24 MB image, or a plugin?).
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).
13. What happens if a table has multiple tbody elements? Do they
sort as independent units, or mingle together? Sorttable just sorts
the first one and ignores the rest, because multiple tbodies are
uncommon, but that's not really acceptable ;-)
Independent.
Hm. They can sort independently, no problem, but how does a user command
a sort of one tbody and not the rest?
They can't.
All the tbodies will identify the same thead tr as their highest one.
This suggests that if you've got
Re: [whatwg] Sortable Tables
On Thu, 27 Dec 2012, Tab Atkins Jr. wrote: On Dec 27, 2012 6:04 PM, Ian Hickson i...@hixie.ch wrote: 2. What values should the sort property allow. One idea is that it takes a JS function similar to what JavaScript's sort function takes. If you leave it out then it just does alphanumeric sort. I was going to have a comparator function, but I couldn't see a sane way to make it work in the face of hostile functions that mutate the DOM, so I dropped it. You can do custom sort orders by giving a key in the data element's value= attribute, though. In JS, the comparator passed to sort() can potentially mutate the array that's being sorted, or delete it entirely. JS engines cope somehow. It's silly to not support a custom comparator here, since any problems you can possibly come up with are already present in the existing Array#sort function. If you can work out how to spec it, I'm all for it. I couldn't figure out how to do it in a way that didn't have a very high chance of being misimplemented and probably becoming an attack vector. I don't think an array is as dodgy as DOM manipulation, by the way. For example, arrays don't have origins, you can't change their prototype by appending the entries to another document, you can't navigate away from an array, you can't make one entry in the array be a child of another entry in the array, when sorting an array you only have one list of entries to sort, not one per column, and you use the same comparator for all entries, you don't mix it with a non-JS comparator. And that's just the problems I could think of off the top of my head; I'm not at all convinced I even understand the problem well enough to enumerate all the issues. Note that using the 'sort' event you can manually implement the sorting if you want to; it'll fire whenever the browser would otherwise sort. So the capability is there, just not in the convenient comparator function form. (Canceling the sort event overrides the UA's normal sorting behaviour.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Sortable Tables
Am 28.12.2012 03:04 schrieb Ian Hickson:
I've added a feature to HTML to enable users (and authors) to sort tables.
The basic design of the feature is that if a column's th has a sorted=
attribute, the UA will sort the table every time the mutation observers
would fire (before they fire). A table can have a sortable= attribute,
which lets the user tell the user agent to add sorted= attributes to
columns to sort them.
This spec is great work! Anyway I have some thoughts on user sorting and
the sort() method - if they are silly, please feel free to ignore them.
I believe that asc and desc would be more intuitive to handle than
and reverse, and I think that some kind of th.sortedState attribute
would be handy, to question the actual state of the table.
Given a basic table such as:
table id=pirates
thead
tr
th sorted=1 id=lastLast name/th
th sorted=2 id=firstFirst name/th
th sorted=3 id=ageAge/th
th sorted=4 id=sexSex/th
/tr
/thead
tbody
tr
tdRead/td
tdMary/td
td25/td
tdf/td
/tr
tr
tdSparrow/td
tdJack/td
td32/td
tdm/td
/tr
...
/tbody
/table
1. If the user clicks on the header Age (or does a respective
interaction provided by the UAs sorting UI), the table should be sorted
by the age column. If ist is already sorted by this column, the sort
direction should be reversed.
2. Authors should be able to provide external links or buttons that can:
- Sort by a column as described in 1.
- Sort by a column, force ascending
- Sort by a column, force descending
I believe that this could be achieved with the following additions:
- a th.sortedstate attribute to question if the table is currently
sorted by this column, and if yes in which direction
- th.sort() method would take an optional argument to indicate the
desired sort direction
The algorithm for th.sort([String direction]) could then be extended
somehow like the following (to be simple I just write th for the
column header element that the method is applied to):
- Temporarily set the column key ordinality of th to 0
- If the direction argument is provided (and valid), temporarily set the
column sort direction to direction
- Else if the sortedstate attribute of th is not null
- if it is asc, temporarily set the column sort direction to desc
- else temporarily set the column sort direction to asc
- Perform the table sorting steps
- Set the sortedstate attributes of all column headers to null
- Set the sortetstate attribute of th to the column sort direction
- Reset the column sort direction and the column key ordinality of th to
their initial values
aside
Furthermore, a table.sort() method would be handy. It could take a comma
separated string as an argument, with each token being the ID of a th,
and optional the direction, such as:
button
onclick=document.getElementById('pirates').sort('sex asc, age')
Order pirates by age, women first. Click again for descending age.
/button
/aside
Re: [whatwg] Sortable Tables
I've added a feature to HTML to enable users (and authors) to sort tables. The basic design of the feature is that if a column's th has a sorted= attribute, the UA will sort the table every time the mutation observers would fire (before they fire). A table can have a sortable= attribute, which lets the user tell the user agent to add sorted= attributes to columns to sort them. On Tue, 6 Nov 2012, Ojan Vafai wrote: On Tue, Nov 6, 2012 at 11:25 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 1 Jul 2010, Christoph P�per wrote: For starters, only rows inside �tbody�s shall be reordered. For now columns don�t have to be reordered, ie. only vertical, no horizontal sorting. Done. Nevertheless the design should make it possible to add the other direction later. Well I guess nothing would stop us supporting sorted= on ths at the front of a row, but boy, that would be a lot more complicated to do. You'd have to be moving cells around all over the place. Not every table has content that makes sense to be sorted in a different order. So sortable tables should be marked as such. Note that �col� and �colgroup� elements are hardly supported. table sortable. 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. Any column with a th is sortable, for now. We can add a nosort column or something later if this becomes a problem. There are different ways to sort, eg. numeric, temporal or alphabetic and ascending or descending. Therefore columns should bear information how they should be sorted, ie. what kind of content their cells have. Ascending/descending is supported (sorted=reversed). Any temporal syntax supported by time can be used by putting time as the only child of the cells to sort. I intend to spec some sort of algorithm for doing numeric/string comparison, but haven't yet come up with a good solution. If you have any suggestions, this is the bug tracking this issue: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20524 Several columns may be used for sorting by some kind of priority. You can set sorted= on multiple columns' headers, and give a sort key cardinality in each, as in sorted=1, sorted=2, etc. The original order must be restorable. This I have not supported. I don't see how to support it sanely. Cell content may not consist of the string that should be used verbatim for sorting purposes, eg. leading articles or similar numbers with different units (�g�, �kg�, �t� �). Cells should have an optional attribute indicating their sort key. The �time� element already provides the necessary metadata features for temporal sorting � maybe there should be more of such elements instead. I've used data for this, alongside time. There may be columns that shall remain stable, eg. rank numbers. I haven't supported this. I've no idea how to do this sanely, especially given cells with column and row spans. 1. Would sorting actually reorder the DOM nodes or just change their visual order? It's not clear to me which one is better. I think the former is what you'd want most of the time. I've gone with reordering the DOM nodes. Things like :nth-child styling become nigh on impossible without doing it at the DOM level, not to mention the confusion that would reign from having such a dramatic disconnect between rendering and DOM (e.g. with abs pos, etc). 2. What values should the sort property allow. One idea is that it takes a JS function similar to what JavaScript's sort function takes. If you leave it out then it just does alphanumeric sort. I was going to have a comparator function, but I couldn't see a sane way to make it work in the face of hostile functions that mutate the DOM, so I dropped it. You can do custom sort orders by giving a key in the data element's value= attribute, though. 3. What elements does it go on? I don't see what it would do on a td. I could see putting it on a th though. Also, it's not clear to me what would get sorted. For example, in some tables, you would group trs inside tbodys and want to sort those. sorted= goes on a column-heading th, ideally in a thead but you can also put it on the first row of your tbody if you don't have a thead. Rows are sorted on a per-group basis. Rows that span each other are treated as one row for sorting. On Tue, 6 Nov 2012, Boris Zbarsky wrote: Another obvious question: how does (or should) sorting interact with rowspans? The sort algorithm groups rows that span each other together and treats them as one (using the data in their top row for sorting). On Wed, 7 Nov 2012, Silvia Pfeiffer wrote: http://tympanus.net/codrops/2009/10/03/33-javascript-solutions-for-sorting-tables/ Interesting, thanks. Also, a sortable table's header needed some indication of the sortability, so some
Re: [whatwg] Sortable Tables
On Dec 27, 2012 6:04 PM, Ian Hickson i...@hixie.ch wrote: 2. What values should the sort property allow. One idea is that it takes a JS function similar to what JavaScript's sort function takes. If you leave it out then it just does alphanumeric sort. I was going to have a comparator function, but I couldn't see a sane way to make it work in the face of hostile functions that mutate the DOM, so I dropped it. You can do custom sort orders by giving a key in the data element's value= attribute, though. In JS, the comparator passed to sort() can potentially mutate the array that's being sorted, or delete it entirely. JS engines cope somehow. It's silly to not support a custom comparator here, since any problems you can possibly come up with are already present in the existing Array#sort function. ~TJ
Re: [whatwg] Sortable Tables
On 12/27/12 7:40 PM, Tab Atkins Jr. wrote: In JS, the comparator passed to sort() can potentially mutate the array that's being sorted, or delete it entirely. JS engines cope somehow. Note that per spec the behavior if the comparator mutates the array is undefined. Engines are allowed to go into infinite loops, crash, throw exceptions, whatever. And sometimes do all of the above. since any problems you can possibly come up with are already present in the existing Array#sort function. This part is true. -Boris
Re: [whatwg] Sortable Tables
On Tue Nov 6 11:25:21 PST 2012, Ian Hickson wrote: [snip] This is a very interesting idea. Is this something browser vendors would be interested in implementing? I'm hesitant to add a feature for this (which could be somewhat involved) before having the definite interest of some browser implementors. I am not representating a browser vendors either a browser developper but I will be welcome to create a javascript polyfill for the sortable table as defined by the WHATWG spec on the current browser supported by the WxT Toolbox. On Tue Nov 6 11:39:35 PST 2012, Ojan Vafai wrote: [snip] A couple thoughts off the top of my head: 1. Would sorting actually reorder the DOM nodes or just change their visual order? It's not clear to me which one is better. I think the former is what you'd want most of the time. From my point of view, the DOM and the associated API should reflect the re-order. That would allow to draw chart on the fly based on user order preference. 2. What values should the sort property allow. One idea is that it takes a JS function similar to what JavaScript's sort function takes. If you leave it out then it just does alphanumeric sort. I agree to takes JS function callback similar to what JavaScript's sort function takes. The callback function can receive the DOM cell element as parameter. Instead of alphanumeric order by default, it would more relevant to have numeric sort then alpha sort. That sort can be base on the first word in the cell then if required goes to next words to complete the comparaison. 3. What elements does it go on? I don't see what it would do on a td. I could see putting it on a th though. Me also, I do not see the value added to apply sort on a td element. Applying sort on th seem an interoperable solution with data table that use the proper markup and are accessible. Also, it's not clear to me what would get sorted. For example, in some tables, you would group trs inside tbodys and want to sort those. My opinion is that depends of the real scope of the th element. If the th is an empty cell or used for layout, the sorting functionality would not be available. If the th is an group header, the sorting functionality would be applied to the header cell along with their data fixed. Where the header cell is a subgroup header or/and an header that represent one or more row or column. If the th is an header, the sorting functionality could be applied to the data cell associated and by default the sorting action would be extended to the other axis [row|col]. I think it is very important to always keep the data relationships with their associated cell headers. This could be required, in the accessibility manner, for a screen reader. I think the vector (col|tr) get sorted in their respective group where the sort is occuring. No group (tbody colgroup) re-ordering should happen during a sorting applied on a cell header related to a vector (tr|col). A group can get ordered only when the sorting action is applied to the group header cell that represent those group. As the concept was already defined in a proposal I made (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-October/037679.html). I would recommand that the sort would not occur in vector (col|tr) into a summary group. But the summary group would always follow their associated data group during the grouping sorting. Also currently there is no spec and/or official best practice on how to get the full potential of the column grouping and the row grouping. Before to enable any kind of official table sorting, the specification should be able to handle properly the complex table relationships, in an accessibility matter, without having the needs to take in consideration the scope attribute and the headers attribute. See the proposal to remove the headers and scope attribute: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-September/037475.html On Tue Nov 6 11:55:06 PST 2012, Boris Zbarsky wrote: [snip] Another obvious question: how does (or should) sorting interact with rowspans? May be the data cells that are rowspans and/or colspans could force the column and/or row related to it to be fixed. That would not break the cell relationships but could make the table imposible to be sorted. Also when a sorting would affect a rowspans/colspans cell, may be only the first cell value in the sorting order can be considerated, the others cell would be ignored. Use case: A data table that have row headers and column headers. Row and column that is in the scope of an rowspans and colspans data cell (td) would be fixed. Use case: A data table that only have row headers. Row that is in the scope of an rowspans data cell (td) would be fixed. Use case: A data table that only have column headers. Column that is in the scope of a colspans data cell (td) would be fixed. On Tue Nov 6 16:17:09 PST 2012, Christoph Päper wrote: [snip] Note that ‘col’ and ‘colgroup’ elements are
Re: [whatwg] Sortable Tables
On Wed, Nov 7, 2012 at 11:42 AM, Simon Pieters sim...@opera.com wrote: On Wed, 07 Nov 2012 10:54:19 +0100, Jirka Kosek ji...@kosek.cz wrote: On 6.11.2012 23:18, Silvia Pfeiffer wrote: * data-type: date, number, text etc which determines the comparison function used in sort It would be very difficult to support sorting on dates and numbers as in HTML they are usually present formatted using specific locale. So there should be additional attribute added to td/th which can hold sort key which will override cell contents, something like td sortas=2012-11-0711. listopadu 2012/td time exists, and data exists for non-time machine-readable data; maybe they can be utilized in some way? I have done some investigation in this area too and having concrete datatypes would make this more utilizable, ie from the proposal for data type= value=/ http://www.w3.org/wiki/User:Cjones/ISSUE-184 The other area of integration would be with BCP-47 language tags and the CLDR which include i18n collation information, for example british numeric collation: en-GB-*u-kn-true* The significant benefit with this is that this standard is already universal across server\client and is of course fully internationalized. The other aspect of this is that there is a distinction between server pagination including sort ordering defining the content of a page and the client-based sorting which would be more of a presentational customization and outside the scope of pagination. As such, it may be better for the HTML to markup the structure of the content with sorting and collation but for this to be configurable through CSS without the structural DOM changes. This could also apply to HTML lists: ul ol, dl. Thanks, Cameron Jones
Re: [whatwg] Sortable Tables
I'm much more inclined to solve this from the data axis. Asking the table itself to do the sorting is weird. Instead, you most often want to have some data source return you rows in sorted order (or indicate row order). If you do something like MDV, sorting the table is applying a sort to the template that stamped out the view. That works with DOM-table backed tables as well as server or JS-backed tables. On Tue, Nov 6, 2012 at 7:39 PM, Ojan Vafai o...@chromium.org wrote: On Tue, Nov 6, 2012 at 11:25 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 1 Jul 2010, Christoph Päper wrote: It's a common task outside HTML to sort tables by one or more of its columns. There does seem interest among web content providers in making tables client-side sortable since there are several Javascript solutions to do just that, eg. http://meta.wikimedia.org/wiki/Help:Sorting, http://tablesorter.com/docs/. From these we can learn what would be needed from markup to help sorting algorithms. None of this must be behaviorial, but descriptionary. For starters, only rows inside ‘tbody’s shall be reordered. For now columns don’t have to be reordered, ie. only vertical, no horizontal sorting. Nevertheless the design should make it possible to add the other direction later. Not every table has content that makes sense to be sorted in a different order. So sortable tables should be marked as such. Note that ‘col’ and ‘colgroup’ elements are hardly supported. 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. There are different ways to sort, eg. numeric, temporal or alphabetic and ascending or descending. Therefore columns should bear information how they should be sorted, ie. what kind of content their cells have. Several columns may be used for sorting by some kind of priority. The original order must be restorable. Cell content may not consist of the string that should be used verbatim for sorting purposes, eg. leading articles or similar numbers with different units (‘g’, ‘kg’, ‘t’ …). Cells should have an optional attribute indicating their sort key. The ‘time’ element already provides the necessary metadata features for temporal sorting – maybe there should be more of such elements instead. There may be columns that shall remain stable, eg. rank numbers. This is a very interesting idea. Is this something browser vendors would be interested in implementing? I'm hesitant to add a feature for this (which could be somewhat involved) before having the definite interest of some browser implementors. This is a use-case that I absolutely think it makes sense to address. This is extremely common whenever people use tables for actual tabular data and it's non-trivial to do in a way that performs well. I'd have to see a more concrete proposal in order to evaluate whether I'd be interested in implementing it. A couple thoughts off the top of my head: 1. Would sorting actually reorder the DOM nodes or just change their visual order? It's not clear to me which one is better. I think the former is what you'd want most of the time. 2. What values should the sort property allow. One idea is that it takes a JS function similar to what JavaScript's sort function takes. If you leave it out then it just does alphanumeric sort. 3. What elements does it go on? I don't see what it would do on a td. I could see putting it on a th though. Also, it's not clear to me what would get sorted. For example, in some tables, you would group trs inside tbodys and want to sort those.
Re: [whatwg] Sortable Tables
Ian Hickson:
On Thu, 1 Jul 2010, Christoph Päper wrote:
Darn, my reply from yesterday got lost in data nirvana. This is a slightly
shorter version thereof.
So sortable tables should be marked as such.
Opt-in:
table sortable collapsible
“sortable=auto” should be the default and resolve to ‘sortable’ if at least one
column has a sort key assigned, and to ‘fixed’ (or the like) otherwise.
(Row and column collapsing is a related, but different beast. Let’s deal with
that separately, later.)
Note that ‘col’ and ‘colgroup’ elements are hardly supported.
Nevertheless, it’s usually sufficient to mark one column as containing values
to use as sort key.
colgroup key=…
col key=…
Columns inherit the key from their group, but may override it.
non-sortable columns inside sortable tables should be marked as such.
key=none
Not to be confused with fixed columns.
There are different ways to sort, eg. numeric, temporal or alphabetic
key=numeric 1 2 10
key=alpha Ä = ä = A#x0308; (= a?), 1 10 2
key=date2012-11-08 = 2012-W45-4
key=value 1000 g = 1 kg = 0.001 t 1 lb
key=style although Excel can do this to some degree, it’s hardly useful
key=class slightly more useful
key=id ditto
and ascending or descending.
That’s better left to the UI: switch order when sorting for the second time.
Several columns may be used for sorting by some kind of priority.
Also primarily a UI question: use previously sorted column as secondary key.
key=1 primary key for heuristic sorting algorithm
The original order must be restorable.
UI again, e.g. tristate column sort: ascending, descending, original, …
Cells should have an optional attribute indicating their sort key.
td value=0.4541 lb
There may be columns that shall remain stable, eg. rank numbers.
key=fixed
The sorting algorithm should not work on cells, but on slots (or slot values
rather).
Cells spanning multiple rows or columns may have to be split into one cell per
slot and should be rejoined afterwards if possible. Note that ‘rowspan’ itself
is safe for vertical sorting, unless it spans a ‘fixed’ column. Also, ‘colspan‘
is safe when it appears in the column to be sorted by.
td {color: green}
[rowspan] {color: red}
trtd1 td rowspan=2red 1 red
trtd3 =sort=col1= 2 green
trtd2 tdgreen 3 red
The text reads its color! A cell at (1,1) – counting starts from 0 – never
exists, the slot at the same position changes its value from ‘red’ to ‘green’.
Re: [whatwg] Sortable Tables
I like this approach. One thing this loses is having default styling for sortable headers. It would be awesome if sortable tables looked the same across pages instead of each page needing to invent their own up/down arrow UI. Also, is MDV intelligent enough to know that you just moved items around or will it clobber and recreate the entire DOM? On Thu, Nov 8, 2012 at 4:17 AM, Alex Russell slightly...@google.com wrote: I'm much more inclined to solve this from the data axis. Asking the table itself to do the sorting is weird. Instead, you most often want to have some data source return you rows in sorted order (or indicate row order). If you do something like MDV, sorting the table is applying a sort to the template that stamped out the view. That works with DOM-table backed tables as well as server or JS-backed tables. On Tue, Nov 6, 2012 at 7:39 PM, Ojan Vafai o...@chromium.org wrote: On Tue, Nov 6, 2012 at 11:25 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 1 Jul 2010, Christoph Päper wrote: It's a common task outside HTML to sort tables by one or more of its columns. There does seem interest among web content providers in making tables client-side sortable since there are several Javascript solutions to do just that, eg. http://meta.wikimedia.org/wiki/Help:Sorting, http://tablesorter.com/docs/. From these we can learn what would be needed from markup to help sorting algorithms. None of this must be behaviorial, but descriptionary. For starters, only rows inside ‘tbody’s shall be reordered. For now columns don’t have to be reordered, ie. only vertical, no horizontal sorting. Nevertheless the design should make it possible to add the other direction later. Not every table has content that makes sense to be sorted in a different order. So sortable tables should be marked as such. Note that ‘col’ and ‘colgroup’ elements are hardly supported. 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. There are different ways to sort, eg. numeric, temporal or alphabetic and ascending or descending. Therefore columns should bear information how they should be sorted, ie. what kind of content their cells have. Several columns may be used for sorting by some kind of priority. The original order must be restorable. Cell content may not consist of the string that should be used verbatim for sorting purposes, eg. leading articles or similar numbers with different units (‘g’, ‘kg’, ‘t’ …). Cells should have an optional attribute indicating their sort key. The ‘time’ element already provides the necessary metadata features for temporal sorting – maybe there should be more of such elements instead. There may be columns that shall remain stable, eg. rank numbers. This is a very interesting idea. Is this something browser vendors would be interested in implementing? I'm hesitant to add a feature for this (which could be somewhat involved) before having the definite interest of some browser implementors. This is a use-case that I absolutely think it makes sense to address. This is extremely common whenever people use tables for actual tabular data and it's non-trivial to do in a way that performs well. I'd have to see a more concrete proposal in order to evaluate whether I'd be interested in implementing it. A couple thoughts off the top of my head: 1. Would sorting actually reorder the DOM nodes or just change their visual order? It's not clear to me which one is better. I think the former is what you'd want most of the time. 2. What values should the sort property allow. One idea is that it takes a JS function similar to what JavaScript's sort function takes. If you leave it out then it just does alphanumeric sort. 3. What elements does it go on? I don't see what it would do on a td. I could see putting it on a th though. Also, it's not clear to me what would get sorted. For example, in some tables, you would group trs inside tbodys and want to sort those.
Re: [whatwg] Sortable Tables
On Thu, Nov 8, 2012 at 8:59 AM, Ojan Vafai o...@chromium.org wrote: On Thu, Nov 8, 2012 at 4:17 AM, Alex Russell slightly...@google.com wrote: I'm much more inclined to solve this from the data axis. Asking the table itself to do the sorting is weird. Instead, you most often want to have some data source return you rows in sorted order (or indicate row order). If you do something like MDV, sorting the table is applying a sort to the template that stamped out the view. That works with DOM-table backed tables as well as server or JS-backed tables. I like this approach. One thing this loses is having default styling for sortable headers. It would be awesome if sortable tables looked the same across pages instead of each page needing to invent their own up/down arrow UI. Agreed, I favor a DOM-based solution because of this. Also, is MDV intelligent enough to know that you just moved items around or will it clobber and recreate the entire DOM? It *should* be intelligent enough to recognize moves, as opposed to just add/deletes. Ask Raf or Adam about their progress on getting this done. ~TJ
Re: [whatwg] Sortable Tables
On Wed, Nov 7, 2012 at 8:37 PM, Jirka Kosek ji...@kosek.cz wrote: On 6.11.2012 23:18, Silvia Pfeiffer wrote: * data-type: date, number, text etc which determines the comparison function used in sort It would be very difficult to support sorting on dates and numbers as in HTML they are usually present formatted using specific locale. So there should be additional attribute added to td/th which can hold sort key which will override cell contents, something like td sortas=2012-11-0711. listopadu 2012/td Agreed. My example was very crude and simple and worked fine for our purposes, but something more generic (and internationalized) needs more functionality like this. Silvia.
Re: [whatwg] Sortable Tables
On 6.11.2012 23:18, Silvia Pfeiffer wrote: * data-type: date, number, text etc which determines the comparison function used in sort It would be very difficult to support sorting on dates and numbers as in HTML they are usually present formatted using specific locale. So there should be additional attribute added to td/th which can hold sort key which will override cell contents, something like td sortas=2012-11-0711. listopadu 2012/td Jirka -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member --
Re: [whatwg] Sortable Tables
I'm the author of http://www.kryogenix.org/code/browser/sorttable/, a
moderately popular JavaScript table sorting script. As such, I have about
nine years worth of anecdata about how authors want their HTML tables to be
sorted, the sorts of things they request, and issues that may be worth
taking into consideration. These are not particularly in order; they're
just things that I think are relevant.
Sorttable.js, my script, has the guiding principle of not needing
configuration in most cases. Therefore, it attempts to guess the type of a
table column: if a column looks like it contains numbers, sorttable will
use numeric sort (1 before 2 before 100) rather than alphanumeric sort (1
before 100 before 2); if a column looks like it contains date information,
then sorttable will sort by date (for formats DD/MM/ and MM/DD/).
The algorithm used for this guessing is pretty naive (check the first cell
in a column; if it's blank, check the next one; etc). I think that this, by
itself, has accounted for sorttable's popularity, because in most cases, it
Just Works; you add a script element pointing to the script, and
class=sortable to the table, and do *nothing else*, and your table is
sortable without any configuration.
Everything else below here is configuration-based: something you'd have to
do explicitly as an author. The above point is the critical one; guessing
column types to make table sorting be zero-config. Some alternative scripts
require you to explicitly tag date or numeric columns, and I think that
authors see that as annoying. Anecdata, of course.
Sorttable also allows authors to specify alternate content for a cell.
That is (ignore the invalid HTML attribute here; I didn't know any better,
and we didn't have data-* attributes when I wrote this stuff)
td sorttable_customkey=11eleven/td
This is basically useful for when you have table data which has a definite
order but it can't be autoguessed, or (more usefully still) when it could
be autoguessed but that would be hard. The canonical example of this is
dates: it would be exceedingly annoying, given
tdWed 7th November, 10.00am GMT/td
to have to parse that cell content in JavaScript to turn it back into a
Date() so it can be placed in sort order with other dates. The sorttable.js
solution is to specify a custom key, which sorttable pretends was the
cell content for the purposes of sorting, so
td sorttable_customkey=20121107-10Wed 7th November, 10.00am GMT/td
and then the script can sort it. This feature is basically the get-out
clause, an author hook for saying I know what I want, but your fancy
sorting thing can't handle it; how do I override that? They can specify
custom keys for all their TDs and then sorting will work fine. (Obviously,
dates are less of a problem in theory today with date elements, but...
how does the script know to use the datetime attribute of the date in
tddate.../date/td?)
In roughly descending order of popularity, here is what I've been asked
questions about, over the last decade or so:
1. Sorting tables inserted after page load. This is obviously not a problem
(sorting a table created with JS rather than in the base HTML), and
sorttable should handle it without explicit action from the author to
mark a table as sortable, but it doesn't because of laziness from me. I
include it for completeness because sorttable not handling it generates
probably a third of all the sorttable complaint email I receive; a properly
specced sortable tables implementation in browsers would obviously handle
this and wouldn't need to even have it specified.
2. Sorting a table on page load. That is: a table in HTML containing
unsorted data should be sorted by the browser when the page loads, without
user action. Sorttable doesn't do this because I think it's wrong (if you
want sorted data when the page loads, serve it as sorted in the HTML), but
lots of people ask for it.
3. Multiple header rows. Many authors have two or more trs in the
thead, one of which contains rowspanned ths, to group columns together.
If this happens, which ths are clickable to sort the table? Which are
not? This is hard to autodiagnose (and indeed sorttable punts on it and
picks the first one, which is almost certainly wrong; even naively picking
the last tr inside thead would be better, but still imperfect).
4. Handling colspans and rowspans in the table. Sorttable.js basically
punts on this, because what's expected to happen when you sort a column
which contains only half a cell (because the other half's in another
column, with rowspan=2) is wildly author-specific. But a properly specced
solution doesn't get to punt and say unsupported. This will need some
thought.
5. Numeric sort handling exponented numbers such as 1.5e6 (which do not
match a naive is this a number regexp such as /^[0-9]+$/ )
6. Specifying how to display that a column is sorted. This would likely be
done in this specification by leaving it to CSS and th::sorted-forward {
after: content(v); }
Re: [whatwg] Sortable Tables
On Wed, 07 Nov 2012 10:54:19 +0100, Jirka Kosek ji...@kosek.cz wrote: On 6.11.2012 23:18, Silvia Pfeiffer wrote: * data-type: date, number, text etc which determines the comparison function used in sort It would be very difficult to support sorting on dates and numbers as in HTML they are usually present formatted using specific locale. So there should be additional attribute added to td/th which can hold sort key which will override cell contents, something like td sortas=2012-11-0711. listopadu 2012/td time exists, and data exists for non-time machine-readable data; maybe they can be utilized in some way? -- Simon Pieters Opera Software
Re: [whatwg] Sortable Tables
On Thu, 1 Jul 2010, Christoph Päper wrote: It's a common task outside HTML to sort tables by one or more of its columns. There does seem interest among web content providers in making tables client-side sortable since there are several Javascript solutions to do just that, eg. http://meta.wikimedia.org/wiki/Help:Sorting, http://tablesorter.com/docs/. From these we can learn what would be needed from markup to help sorting algorithms. None of this must be behaviorial, but descriptionary. For starters, only rows inside ‘tbody’s shall be reordered. For now columns don’t have to be reordered, ie. only vertical, no horizontal sorting. Nevertheless the design should make it possible to add the other direction later. Not every table has content that makes sense to be sorted in a different order. So sortable tables should be marked as such. Note that ‘col’ and ‘colgroup’ elements are hardly supported. 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. There are different ways to sort, eg. numeric, temporal or alphabetic and ascending or descending. Therefore columns should bear information how they should be sorted, ie. what kind of content their cells have. Several columns may be used for sorting by some kind of priority. The original order must be restorable. Cell content may not consist of the string that should be used verbatim for sorting purposes, eg. leading articles or similar numbers with different units (‘g’, ‘kg’, ‘t’ …). Cells should have an optional attribute indicating their sort key. The ‘time’ element already provides the necessary metadata features for temporal sorting – maybe there should be more of such elements instead. There may be columns that shall remain stable, eg. rank numbers. This is a very interesting idea. Is this something browser vendors would be interested in implementing? I'm hesitant to add a feature for this (which could be somewhat involved) before having the definite interest of some browser implementors. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Sortable Tables
On Tue, Nov 6, 2012 at 11:25 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 1 Jul 2010, Christoph Päper wrote: It's a common task outside HTML to sort tables by one or more of its columns. There does seem interest among web content providers in making tables client-side sortable since there are several Javascript solutions to do just that, eg. http://meta.wikimedia.org/wiki/Help:Sorting, http://tablesorter.com/docs/. From these we can learn what would be needed from markup to help sorting algorithms. None of this must be behaviorial, but descriptionary. For starters, only rows inside ‘tbody’s shall be reordered. For now columns don’t have to be reordered, ie. only vertical, no horizontal sorting. Nevertheless the design should make it possible to add the other direction later. Not every table has content that makes sense to be sorted in a different order. So sortable tables should be marked as such. Note that ‘col’ and ‘colgroup’ elements are hardly supported. 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. There are different ways to sort, eg. numeric, temporal or alphabetic and ascending or descending. Therefore columns should bear information how they should be sorted, ie. what kind of content their cells have. Several columns may be used for sorting by some kind of priority. The original order must be restorable. Cell content may not consist of the string that should be used verbatim for sorting purposes, eg. leading articles or similar numbers with different units (‘g’, ‘kg’, ‘t’ …). Cells should have an optional attribute indicating their sort key. The ‘time’ element already provides the necessary metadata features for temporal sorting – maybe there should be more of such elements instead. There may be columns that shall remain stable, eg. rank numbers. This is a very interesting idea. Is this something browser vendors would be interested in implementing? I'm hesitant to add a feature for this (which could be somewhat involved) before having the definite interest of some browser implementors. This is a use-case that I absolutely think it makes sense to address. This is extremely common whenever people use tables for actual tabular data and it's non-trivial to do in a way that performs well. I'd have to see a more concrete proposal in order to evaluate whether I'd be interested in implementing it. A couple thoughts off the top of my head: 1. Would sorting actually reorder the DOM nodes or just change their visual order? It's not clear to me which one is better. I think the former is what you'd want most of the time. 2. What values should the sort property allow. One idea is that it takes a JS function similar to what JavaScript's sort function takes. If you leave it out then it just does alphanumeric sort. 3. What elements does it go on? I don't see what it would do on a td. I could see putting it on a th though. Also, it's not clear to me what would get sorted. For example, in some tables, you would group trs inside tbodys and want to sort those.
Re: [whatwg] Sortable Tables
On 11/6/12 11:39 AM, Ojan Vafai wrote: This is a use-case that I absolutely think it makes sense to address. Agreed. Not that I can commit to implementing, necessarily, but I do think this is a common want. A couple thoughts off the top of my head: 1. Would sorting actually reorder the DOM nodes or just change their visual order? It's not clear to me which one is better. I think the former is what you'd want most of the time. The former also makes defining the interaction of dynamic mutations with sorting much much simpler Another obvious question: how does (or should) sorting interact with rowspans? -Boris
Re: [whatwg] Sortable Tables
On Wed, Nov 7, 2012 at 6:55 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/6/12 11:39 AM, Ojan Vafai wrote:
This is a use-case that I absolutely think it makes sense to address.
Agreed. Not that I can commit to implementing, necessarily, but I do
think this is a common want.
Great to hear browser interest! It's something I've had to implement for
basically all Web apps I've been involved with developing, so am really
keen to get browsers to take this over.
Not quite new, but a good requirements analysis can be had from the list of
JS solutions here:
http://tympanus.net/codrops/2009/10/03/33-javascript-solutions-for-sorting-tables/
I our apps, we'd typically not associate sortable to the table, but to a
column header.
Typical classes/attributes we'd add to a table header cell:
* sortable class: boolean
* data-direction: ascending/descending
* data-type: date, number, text etc which determines the comparison
function used in sort
* data-sort-prio: numeric indicating sorting priority
Also, a sortable table's header needed some indication of the sortability,
so some default CSS like this:
th.sortable {
:after { content: ▲▼}
.current{
[data-direction=asc]:after { content: ▼}
[data-direction=desc]:after { content: ▲}
}
}
HTH...
Cheers,
Silvia.
Re: [whatwg] Sortable Tables
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=numeric1 = 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, TheThe Rolling Stones
td value=0.4541 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;}
trtd3 td id=split colspan=2 red
trtd1
trtd2 td green
after sorting by the first column should look like
trtd1 td id=split red
trtd2 td green
trtd3 td id=split red
would if duplicate IDs were
Re: [whatwg] Sortable Tables
On Thu, Jul 1, 2010 at 11:38 AM, Christoph Päper christoph.pae...@crissov.de wrote: I have not found much on sortable tables on whatwg.org, especially when excluding ‘datagrid’. Why are you excluding datagrid, when that's the precise element aimed at addressing your issue? PK
Re: [whatwg] Sortable Tables
Peter Kasting: Why are you excluding datagrid, when that's the precise element aimed at addressing your issue? Because of r3555 http://lists.whatwg.org/htdig.cgi/commit-watchers-whatwg.org/2009/002723.html where it was removed and because I don’t think this requires a new element at all.
