Intent to Implement: HTML5 Table Sorting API

[Caitlin Potter]

Contact emails

caitpo...@gmail.com

Spec

http://www.whatwg.org/specs/web-apps/current-work/multipage/tables.html#table-sorting-model

http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-data-element

http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-time-element

Summary

HTMLTableElement's sorting DOM api to be exposed, particularly HTMLTableHeaderCell#sort(), and HTMLTableElement#stopSorting(). Sorting-enabled tables to automatically re-sort when subtree changes.

A side-effect of implementing this feature is implementing the HTML5 <data> and <time> elements, which play a role in helping to calculate machine-readable (sortable) values for table cells.

Motivation

Currently, it's necessary to use javascript to perform sorting of tables. Javascript can perform this task well, and has the ability to let users customize their comparison predicates. However, as a convenience to developers, and as a way of improving the performance and correctness of applications which use this behaviour, it's desirable to implement this natively.

Compatibility Risk

Currently, the Table Sorting Model (and related DOM api) are not implemented in any browsers. Gecko has shipped the HTMLDataElement and HTMLTimeElement, which block correctly implementing the table sorting model, since FF22.

Ongoing technical constraints

None

Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes

OWP launch tracking bug?

There is no launch-tracking bug.

Link to entry on the feature dashboard

There is no entry on the dashboard.

Requesting approval to ship?

No.

[Philip Rogers]

Can you expand on why this should be implemented natively instead of part of an external javascript library?

[Elliott Sprehn]

I don't think we want this in the engine, it should be implemented as a library. In my experience automatic data type analysis rarely works in business applications, so you need pretty heavy customization for your domain.

Instead of trying to bake so much into the platform someone should create a web components library that supports Hixie's spec. :)

On Tue, Aug 26, 2014 at 12:54 PM, Caitlin Potter <caitpo...@gmail.com> wrote:

[Elliott Sprehn]

+blink-dev

---------- Forwarded message ----------
From: Caitlin Potter <caitpo...@gmail.com>
Date: Tue, Aug 26, 2014 at 1:09 PM
Subject: Re: [blink-dev] Intent to Implement: HTML5 Table Sorting API
To: Elliott Sprehn <esp...@chromium.org>

I have raised the concern that custom sorting predicates would be useful, and it may be possible to change the spec to enable those, making the feature more useful for business applications in the future. With a pref-disabled implementation, it should be possible to eat the dog food and see how problematic the default sorting algorithm really is, and if it turns out to not be enough, there will at least be data to feed back to the spec.

Caitlin Potter

caitpo...@gmail.com

[Caitlin Potter]

There are a few reasons why you’d want to see this natively:

1. Look and feel: Natively implementing the sorting UI will allow the look and feel of the sorting UI to match what would be expected from the browser or operating system.

2. Performance: We can do all of the work of re-sorting a table without triggering multiple reflows. While this is technically possible in a script, it’s somewhat more difficult to ensure that the order of operations prevents multiple reflows. Implementing the feature natively also allows for the caching of sortable values, which prevents them from being needlessly recalculated.

Caitlin Potter

caitpo...@gmail.com

[Adam Barth]

We shouldn't bake this feature into the platform.  Folks should implement it themselves using web components.  In fact, people are already doing that:

http://component.kitchen/components/sortable-table

On Tue Aug 26 2014 at 1:33:42 PM Caitlin Potter <caitpo...@gmail.com> wrote:

There are a few reasons why you’d want to see this natively:

1. Look and feel: Natively implementing the sorting UI will allow the look and feel of the sorting UI to match what would be expected from the browser or operating system.

I doubt many sites will want to match the look-and-feel of the platforms table sorting widget.  That's pretty obscure.

2. Performance: We can do all of the work of re-sorting a table without triggering multiple reflows. While this is technically possible in a script, it’s somewhat more difficult to ensure that the order of operations prevents multiple reflows. Implementing the feature natively also allows for the caching of sortable values, which prevents them from being needlessly recalculated.

That's why web components are a good fit for this problem.  One person can do the hard work of making a high quality sortable-table element and everyone can benefit from their work.

Adam

[Daniel Bratell]

On Wed, 27 Aug 2014 04:47:50 +0200, Adam Barth <aba...@chromium.org> wrote:

We shouldn't bake this feature into the platform.  Folks should implement it themselves using web components.  

It looks like Hixie added it to the HTML specification a year and a half ago and the only response on the whatwg mailing list was that it was "great". If blink architects don't think it's a good HTML feature then Hixie and the other spec editors should be told (adding CC).

/Daniel

[Ian Hickson]

On Wed, 27 Aug 2014, Adam Barth wrote:
>
> We shouldn't bake this feature into the platform. Folks should implement
> it themselves using web components.

There's nothing special about Web components here. People have made
scripts that do this for years. It's because we know that people have made
scripts for this that we know that there's demand for the feature, which
is why it eventually was turned into a feature in the spec.

I don't buy the theory that anything that can be replicated in scripts
shouldn't be provided natively. You can do all kinds of things with
scripts. Form submission, layout, checkboxes, responsive design, etc.
Doesn't mean we shouldn't support these natively.

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

[Darin Fisher]

On Wed, Aug 27, 2014 at 3:32 PM, Ian Hickson <i...@hixie.ch> wrote:

On Wed, 27 Aug 2014, Adam Barth wrote:
>
> We shouldn't bake this feature into the platform.  Folks should implement
> it themselves using web components.

There's nothing special about Web components here. People have made
scripts that do this for years. It's because we know that people have made
scripts for this that we know that there's demand for the feature, which
is why it eventually was turned into a feature in the spec.

I don't buy the theory that anything that can be replicated in scripts
shouldn't be provided natively. You can do all kinds of things with
scripts. Form submission, layout, checkboxes, responsive design, etc.
Doesn't mean we shouldn't support these natively.

The platform is already very big. It seems unfortunate to add unnecessary

things to it. We should add what is necessary to enable others to innovate

(e.g., for frameworks to add convenient utilities for developers).

-Darin

[Caitlin Potter]

For what it's worth, it just seemed like a fun thing to work on in my free time.

I think it would be a pretty neat feature to add, but it is true that it's not a non-trivial amount of code to add all of this stuff, and I'm sure an extra pile of maintenance headache isn't what anyone is looking for. Maybe it won't get to happen :(

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Elliott Sprehn]

I've expressed my opinion to Hixie both in person and on IRC over the past year. I believe the goals of the Blink team related to exposing primitives and paving the path for an extensible web have been pretty clear over the past year as well.

We need to focus on making the platform fast and exposing primitives so authors don't need to wait years for us to figure out each API. I don't think there's anything missing in the platform right now related to building a table sorting framework.

- E 

[Jonas Sicking]

On Wed, Aug 27, 2014 at 3:32 PM, Ian Hickson <i...@hixie.ch> wrote:

> You can do all kinds of things with
> scripts. Form submission, layout, checkboxes, responsive design, etc.
> Doesn't mean we shouldn't support these natively.

The problem with supporting things natively, is meeting the 80% use
case in a single API. Forms is a great example of this where more and
more websites build their own forms because the browser provided one
doesn't meet their needs. Usually it's because they look too ugly and
can't be styled as needed, other times it's because some aspect of the
functionality just isn't there.

Another problem is of course that it usually takes years for platform
features to get enough marketshare that authors actually get benefit
from using them, rather than just rely on libraries.

Obviously these things are always judgement calls. For example many
authors are very exited about lots of features of ES6, even though
they are effectively just sugar for existing functionality.

In the case of table sorting, I haven't heard much excitement at
mozilla for implementing. Especially given how lacking similar
features, like form controls, are, and the resulting frustration from
developers.

/ Jonas

[Adam Barth]

Rather than adding a low value feature, would you consider making the system faster instead?  That's much more valuable to the project.

If you're looking for an interesting performance bug, I'd recommend looking at https://code.google.com/p/chromium/issues/detail?id=313562 (or maybe something else from the Jank hotlist: https://code.google.com/p/chromium/issues/list?q=label:Hotlist-Jank).

Adam

[Mathias Bynens]

On Thu, Aug 28, 2014 at 1:05 AM, Adam Barth <aba...@chromium.org> wrote:
> Rather than adding a low value feature, would you consider making the system
> faster instead? That's much more valuable to the project.

Wouldn’t a decent native C++ table sorting implementation be faster
and more efficient than anything users can script themselves?

Especially on low-end mobile devices sorting large tables in the DOM
is very slow. Any speedups in that area would bring the Web more on
par with native apps, and are more than welcome IMHO.

[Philip Rogers]

Mathias,

If the table is so large that sorting is slow, rebuilding the DOM after sorting will be the bottleneck. Improving our table layout performance would be a huge win across the board.

[Adam Barth]

On Wed Aug 27 2014 at 10:43:39 PM Mathias Bynens <math...@opera.com> wrote:

On Thu, Aug 28, 2014 at 1:05 AM, Adam Barth <aba...@chromium.org> wrote:
> Rather than adding a low value feature, would you consider making the system
> faster instead?  That's much more valuable to the project.

Wouldn’t a decent native C++ table sorting implementation be faster
and more efficient than anything users can script themselves?

I doubt it.  Even if the theoretical maximum speed was greater for a built-in implementation, this feature is too esoteric to work well.  For example, theoretically, CSS counters should be faster than script-implemented counters because they're integrated with the engine, but the truth is that they're much slower because the C++ implementation is unloved.

These sorts of long-tail features don't work well in the cathedral economics of a rendering engine.  Instead, they're much better suited to the the bazaar economics of web components.

Adam

[Alex Russell]

I concur with Adam, but oppose implementing this for additional reasons: as spec'd, this is a pile of unpluggable magic.

Sorting cannot be neatly delegated to a custom script or sent to the server for (possibly paginated data) updates. The types are welded shut and the addressed use-cases, frankly, make a mockery of the richness of sorting systems that Hixie appeals to as the script precedents.

If we're going to add sorting to tables it should happen by explaining the system, making it pluggable -- and making it async friendly -- not larding it up with syntax and magic.

Regards

[Morten Stenshorne]

Philip Rogers <p...@chromium.org> writes:

> Improving our table layout performance would be a huge win across the
> board.

Out of curiosity, what performance improvements do you have in mind?

--
---- Morten Stenshorne, developer, Opera Software ASA ----
------------------ http://www.opera.com/ -----------------

[Ian Hickson]

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.

[Alex Russell]

On Thu, Aug 28, 2014 at 9:02 AM, Ian Hickson <i...@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 but my read of the processing 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