3 ms·
> 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 a
by 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 agoAll 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 agoAuto-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...."