It has to handle every possible use case for a grid. You’re thinking of your use case. The spec needs to handle everything else. I don’t see how that’s manageable.
A good spec really only needs clear principles. At a minimum, it should clearly explain what it does do, and also clearly explain what it does not do.
You don't need to have every edge case covered to build an API for datagrids. iOS has had native DataGrids for ages, Windows, macOS, Android. They all have this stuff built in. Other platforms have figured out how to provide these API surfaces.
Why does the web have to be seen as a special unicorn that can't have good baseline components like these platforms?
That’s why the web is a special unicorn. It’s very different than those platforms. Web standards should be small and composable. They shouldn’t try to solve every problem. I get why you would want a data grid. Maybe in your work it’s a common pattern. But on the broader web and in all of the documents that are out there, it’s on a minute fraction of them. It’s simply not worth the effort. Too much effort, too little gain.
ECMAScript / JavaScript. It has evolved at a faster pace since the introduction of ES6, and we been getting new features every year for awhile now. Given the types of features they're willing to ship with the languag and that many of the same people working on the HTML spec work on ECMAScript, it seems 'niche' isn't an issue (simply look at how many features have been added specifically only for classes vs the amount that the language construct of class is actually used. Its tiny in usage, but they've added alot of class specific features)
Other notable examples include the C and C++ standards (there are differing vendor implementations depending on platform which while annoying are largely well known how to navigate). Linux operating systems - the amount of incompatibility between linux distros is shockingly small all things considered.
I'm sure there are others I'm not able to think of as well, but this isn't special to the web by any means.
Pagination could be argued as well, but at least that's simple-ish to implement (but still, it's such a common UI pattern that it ought to be handled in a unified way by browsers IMO)
If it has to take decades to agree on a design for a stylable select box, then there is something fundamentally broken with the approach.
While maybe you could imagine a straightforward technical implementation (and I think you’re overlooking the complexity of getting the API right while making it extensible), the social engineering involved to make this happen would be Herculean. And it would be for an element that’s on less than 1% of web pages. If you really want a data grid, I’d suggest learning how to code one. It’s a fun challenge, and implementing basic features like sorting and filtering isn’t difficult using a modern framework. If it is difficult for you, then I’d suggest that it would be a GREAT experience to try. Then imagine how you’d make it extensible for unknown use cases.
The main reason it took decades for a stylable select box is because for two decades, we were just told “Don’t style select boxes. It’s bad for usability,” which was a mistake. We’ve only started to overcome that mindset in the past few years. The work on stylable select boxes only started in the past few years.
There's a difference between design-by-committee, and approval by committee. I'm arguing against the former. This is not to say that I have much hope that my approach will prevail, but it is an indictment of the W3C/WHATWG that they have not figured out a better process for producing technically excellent and coherent designs/specs in reasonable time.
Just invite submissions from small teams that each have produced a coherent design, and then the hard process of agreeing/voting on them will be a bit easier.
> If you really want a data grid, I’d suggest learning how to code one.
I have designed and implemented highly sophisticated data grids, and I have published related libraries on NPM. I wonder what in my comments makes you think I lack the competence or experience to implement one.
The problem is the JS bloat that we have to deal with. It is ugly that we have to load megabytes of JS to render any reasonably sophisticated web UI. Multiply that by the millions of sites that have to do that, plus all the upstream dependencies that are loaded with that, and also consider all the security/privacy issues with so much JS, and hopefully you'll begin to understand the critical need for a revamp of the HTML space.