2 ms·

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 o

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

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...."