3 ms·

A lot of things should have been part of HTML 20 years ago. Table sorting comes immediately to mind. No reason that should require JS for very straightforward c

A lot of things should have been part of HTML 20 years ago. Table sorting comes immediately to mind. No reason that should require JS for very straightforward cases, and almost none should need more than to define a sort function (or a few sort functions, given many columns), provided the table fits on one page. That's a no-brainer even if the web hadn't taken a turn to being the lowest-common-denominator app delivery platform. Given that's happened, there's a bunch more that should have been added, if not 20 years ago, certainly 10, to make it at least sort of resemble an actual GUI toolkit, in capabilities.

wvenable 5y ago
Every sortable table I have ever coded sourced it's data from a large database-backed data source. So sorting always requires a server call to fetch new data for the view. In my opinion, a client-side only table sorting only solves a very small unlikely niche -- so small that's not worth doing.
- handrous 5y ago
  Small and unlikely?! Wikipedia alone has thousands of them, and that's a safe, low guess. Probably tens of thousands. And there are lots of single-page tables on the Web that don't have sorting implemented, but that a user might wish to sort. [EDIT] further, aside from that being a great feature for vanilla HTML even if it had continued to only be a document format, that's a great stepping stone on the way to having proper, datasource-backed tables, as is common in mature GUI widget frameworks and libraries.
  - wvenable 5y ago
    What are the odds that the browser will be able to implement the one-size-fits-all sorting necessary to make the thousands of Wikipedia tables sort properly and look decent while doing it? A browser-based implementation would be the lowest common denominator that would likely only be used when neither style or accuracy is required. Not unlike <datalist>. I already replace every single browser form-field convenience with JavaScript/CSS based alternative that works better, looks better, and plays nicer with backend technologies. Implementing fully complete features in HTML seems like the wrong approach to me; I'd rather browsers provide the necessary low-level building to do it in code. It's much more future proof and flexible that way.
    - handrous 5y ago
      > What are the odds that the browser will be able to implement the one-size-fits-all sorting necessary to make the thousands of Wikipedia tables sort properly and look decent while doing it? Approaching 1? > I already replace every single browser form-field convenience with JavaScript/CSS based alternative that works better, looks better, and plays nicer with backend technologies. Implementing fully complete features in HTML seems like the wrong approach to me; I'd rather browsers provide the necessary low-level building to do it in code. It's much more future proof and flexible that way. This is exactly the problem, if browsers are now our LCD GUI toolkits (and they are). You absolutely should not need to do that. The proof that this is feasible is present in... well, most other major GUI toolkits. The wasted time, wasted cycles, and broken features (especially, but not exclusively, a11y) due to HTML being so bad at being the thing we're trying to make it be are all avoidable problems, not hypothetically, but in fact.
      - wvenable 5y ago
        All major GUI toolkits are customizable in just the same way -- with code. Desktop GUI toolkits don't auto-sort table data either -- you're still expected to code that.
        handrous 5y ago
        Auto-sortability should have been there in HTML's capacity as a document format. All the hooks & interactive elements necessary for custom sorting with little more than a definition for a given column's sort function and some toggles for the various features, should be there now. It's absurd to have to start either by importing a library (which one? Why is this even a choice one must make?) or by leading with "OK, this th cell should have such-and-such onClick handler...."

wvenable 5y ago

Every sortable table I have ever coded sourced it's data from a large database-backed data source. So sorting always requires a server call to fetch new data for the view. In my opinion, a client-side only table sorting only solves a very small unlikely niche -- so small that's not worth doing.

handrous 5y ago
Small and unlikely?! Wikipedia alone has thousands of them, and that's a safe, low guess. Probably tens of thousands. And there are lots of single-page tables on the Web that don't have sorting implemented, but that a user might wish to sort. [EDIT] further, aside from that being a great feature for vanilla HTML even if it had continued to only be a document format, that's a great stepping stone on the way to having proper, datasource-backed tables, as is common in mature GUI widget frameworks and libraries.
- wvenable 5y ago
  What are the odds that the browser will be able to implement the one-size-fits-all sorting necessary to make the thousands of Wikipedia tables sort properly and look decent while doing it? A browser-based implementation would be the lowest common denominator that would likely only be used when neither style or accuracy is required. Not unlike <datalist>. I already replace every single browser form-field convenience with JavaScript/CSS based alternative that works better, looks better, and plays nicer with backend technologies. Implementing fully complete features in HTML seems like the wrong approach to me; I'd rather browsers provide the necessary low-level building to do it in code. It's much more future proof and flexible that way.
  - handrous 5y ago
    > What are the odds that the browser will be able to implement the one-size-fits-all sorting necessary to make the thousands of Wikipedia tables sort properly and look decent while doing it? Approaching 1? > I already replace every single browser form-field convenience with JavaScript/CSS based alternative that works better, looks better, and plays nicer with backend technologies. Implementing fully complete features in HTML seems like the wrong approach to me; I'd rather browsers provide the necessary low-level building to do it in code. It's much more future proof and flexible that way. This is exactly the problem, if browsers are now our LCD GUI toolkits (and they are). You absolutely should not need to do that. The proof that this is feasible is present in... well, most other major GUI toolkits. The wasted time, wasted cycles, and broken features (especially, but not exclusively, a11y) due to HTML being so bad at being the thing we're trying to make it be are all avoidable problems, not hypothetically, but in fact.
    - wvenable 5y ago
      All major GUI toolkits are customizable in just the same way -- with code. Desktop GUI toolkits don't auto-sort table data either -- you're still expected to code that.
      - handrous 5y ago
        Auto-sortability should have been there in HTML's capacity as a document format. All the hooks & interactive elements necessary for custom sorting with little more than a definition for a given column's sort function and some toggles for the various features, should be there now. It's absurd to have to start either by importing a library (which one? Why is this even a choice one must make?) or by leading with "OK, this th cell should have such-and-such onClick handler...."