Re: <table type="rowsortable">

As you noted, the sort order for a column may be dependent on the
application.  Trying to enumerate all possible combinations is going to be
painful (for the browser implementors), and incomplete.

Also if you have more than one column of data, you probably want some
secondary keys (to determine the order of rows where the primary key is
equal).  The secondary key might be another column, or it might be data not
in the table.

Implementations of complex specifications tend to differ.  The differences
cause pain for application developers.  Responsible vendors are going to
preserve backwards compatibility, so the differences are going to be
permanent.

KISS the problem.  There is some value in declaring a column as sortable, as
the browser could present all sortable columns with a consistent
appearance.  For sorting, you cannot cover all the application-specific
cases, so don't try.  Default to a simple alpha sort, and allow script to
plug in sort functions to override the default.

Oddly enough, in the first two cases where I had a need for sortable tables
in an application, the first required a round-trip to the server
(application semantics), and the second ended up using a secondary key from
data not in visible table.  Perhaps this is atypical, but the result is I
cannot see putting the browser implementors to a lot of pain - for function
I would have had to override.



On 4/7/07, Dailey, David P. <david.dailey@sru.edu> wrote:
>
>
> Preston Bannister wrote:
> >This is behavior, and better implemented in script.
>
> >The browser does not have enough information to sort.  Declarative markup
> is doomed to be incomplete, >compared to behavior that can be implemented in
> script.
>
> Generally, I'd tend to agree, if it weren't for the inconsistencies of
> DOM's and CSS implementations, which make writing a script to do so obvious
> a thing, completely nontrivial.
>
> I think there are six or eight obvious ways of sorting a single column,
> together with infinitely many other less obvious ways. It sounds like a list
> of attribute values could handle the obvious ones. Yes, there are
> alternative ways of representing numbers (Roman numerals, base 10,
> comma-delimited etc.) and there are alternative ways of representing dates
> -- but sprinkled widely throughout existing W3C specs I see references to
> "allowable" data types, so it seems like a wee bit of inspired analysis
> could easily pick off the 85% of the cases authors would most likely wish to
> use.
>
> Is it worse to bulk up the browser with well-written compiled code or to
> bulk up the web with bloated quirks-mode client side scripts? Are we making
> life easier for authors or for browser developers? I think a lot of authors
> would love it.
>
> I guess I remain unconvinced of the futulity of this.
>
> I agree with Anne van Kesteren that the WHATWG considers active tables
> from a much broader perspective than the sortable tables concept I
> suggested, though I didn't see quite the same functionality in there
> (perhaps I'm just missing it). In general, I like the way WHATWG seems to
> have considered the broader issues pertaining to active tables however. If
> someone needs a more modest proposal for some future compromise of some
> sort, then "sortable tables" could be it.
>
> David Dailey
>