Of course most JavaScript-based tables get this wrong, too.
But thinking about it: Is there a precedent for HTML to be able to include information that instructs the device to present the DOM out of order? Maybe it's out of scope for HTML to have information about presentation order, when the order is supposed to be implied strictly by the DOM hierarchy itself.
Of course, CSS can visually reorder stuff (e.g. `order` on flex/grid items), but MDN has accessibility warnings regarding the use of `order` and visually presenting the data in an order not reflected by the DOM. So, maybe sorting is best done by reordering the DOM after all.
Yes, it can be done with JS, but nothing is going to beat the browser engine for frequent DOM manipulation of that sort. It's also just one less dependency to have to pull in.
HTML describes layout, CSS describes style, JS adds interactivity.
Want sortable tables? Get a jquery plugin and spend five minutes, done.
This was all solved a decade or more ago.
News to me.
If HTML had <inline> <block> <column> <row> or <grid> tags, sure. But CSS determines the layout via display/position properties.
<div> is block
<table>,<tr> and <td> are your grid, row and column.
CSS improves on describing layout with positioning but HTML was still doing that before CSS even came along.
> explicitly and implicitly describe the layout of an HTML document.
No, this doesn't happen.
> In fact, "HTML" itself is an acronym (HyperText Markup Language)
Duh.
> in which the "Markup" describes the function of HTML to "mark up" text in a similar way that editors once did in the print industry, describing which parts of the text should be bold, italicized, etc. or divided up and in what way.
Which has fuck-all to do with the layout.
I want sortable tables without having to rely on a third-party plugin to a third-party library. HTML describes content, not just layout. It would be a `sortable` attribute on the table, just like you already have attributes that have nothing to do with layout such as `autocomplete` or `aria-*`.
It's all fine and dandy until marketing bros decide to shove all kinds of shady modals into that JS file. The JS side is not exclusive to trivial interactivity.
It's open source software. You can see what it does, and you just put it on your server. We're talking about pre NPM javascript here, no continuous deployment, everything is vendored and local and no one is going to change that file without your knowledge and permission. And if someone does, you have much bigger problems on your hands.
What you can't own and control is the browser vendors and how they choose to implement things, or not to. You can edit a JS file to your specific needs, but you're stuck with whatever the browser decides.
There is an incentive to use HTML for common interactivity purposes.
It's really easy to do this with server rendered HTML. Put a link with the sort param in the column headers and be done.
It does make sense in one situation, if the table is a large server-side paginated one and the sorting is really an ORDER BY clause. But for a basic table that fits entirely on the client, it doesn't make sense at all. There are tiny JS libraries that will make <table>s sortable when you add a particular class name.
What are some good ones?
It is far more resources hungry when dealing with beyond 50 rows or more.
Puts needless pressure on backend.
It is not a good idea when sending whole dataset to client is feasible/better choice.