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.
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
Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?
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?
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.
We shouldn't bake this feature into the platform. Folks should implement it themselves using web components.
On Wed, 27 Aug 2014, Adam Barth wrote:There's nothing special about Web components here. People have made
> We shouldn't bake this feature into the platform. Folks should implement
> it themselves using web components.
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.
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 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.
On Thu, 28 Aug 2014, 'Alex Russell' via blink-dev wrote:Actually the API intentionally fires an event before sorting precisely to
> I concur with Adam, but oppose implementing this for additional reasons: as
> spec'd, this is a pile of unpluggable magic.
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.