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 <ojan@chromium.org> wrote:

> On Tue, Nov 6, 2012 at 11:25 AM, Ian Hickson <ian@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.
>

Received on Thursday, 8 November 2012 12:19:39 UTC