Re: [blink-dev] Intent to Implement: HTML5 Table Sorting API

On Thu, Aug 28, 2014 at 9:02 AM, Ian Hickson <ian@hixie.ch> wrote:

> On Thu, 28 Aug 2014, 'Alex Russell' via blink-dev wrote:
> >
> > I concur with Adam, but oppose implementing this for additional reasons:
> as
> > spec'd, this is a pile of unpluggable magic.
>
> Actually the API intentionally fires an event before sorting precisely to
> allow this kind of thing. If you have any better ideas for how the API
> should work, though, I encourage you to mail the whatwg list.


Perhaps you can clarify for me how this is meant to be extensible, 'cause
I'm not seeing it.

The `sort` event *is* cancellable
<http://www.whatwg.org/specs/web-apps/current-work/multipage/indices.html#event-sort>
but my
read of the processing model
<http://www.whatwg.org/specs/web-apps/current-work/multipage/tables.html#table-sorting-model>
suggests that if it is canceled, the browser UI for indicating sorting
isn't provided. I.e., you can cancel sorting but you can't collaborate with
the system on sorting. Further, the underlying data model isn't exposed.
Step 4 of the row-group comparison further hard-codes in a sort comparison
precedence and, AFAICT, step 3 derives data models from specific markup
patterns but doesn't let the developer either provide their own data in a
pluggable way (how do I extend a TD to provide my own sortable information
that isn't in one of the magical child element types?).

Further, it isn't possible to simply over-ride the internal comparison
function (as you can with Array.prototype.sort() in JS) leaving a gaping
impedance mismatch between developer expectation and system-provided
behavior.

Unless I'm missing a large bit of API/IDL (possible, nay, likely!...please
correct me if I have missed something), table sorting in HTML 5 is a
tour-de-force of non-extensible design. The closed data model, the
spooky-behavior-at-a-distance, the cancellable-but-not-pluggable
functionality that has no API or explanation...it's from a time before
extensiblewebmanifesto.org. There's good stuff in there that's crying out
for API, and I'm happy to sit down with you and design something better,
but I'm not going to do it (first) on a mailing list.

Regards