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.

Does it though?

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?

Are any of the examples you gave an open standard with multiple implementations from different companies? If Apple gets their implementation wrong, they can always deprecate an API and move forward. If they want to throw out an old implementation and deprecate that completely and start over, they can do that. The Web standard depends on agreement by multiple large organizations. That level of communication slows everything down. If they get an API wrong, we’re stuck with it forever.

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.

>Are any of the examples you gave an open standard with multiple implementations from different companies?

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.

At minimum filtering and sorting should be handled by the browser, including async for both of those.

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)

Look at how much effort has gone into just getting a stylable select box. Look at tooltips. A data grid is several orders of magnitude higher in complexity than both of these. You are severely underestimating the complexity of your ask. HTML/JS/CSS is not supposed to solve all your UX problems. It’s a toolkit for building UIs, not a framework.

Is it not the design by committee approach that slows down the design consensus on things like these? Just complex is it to design a spec for a stylable select box that is reasonable for most use cases?

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.

For an open standard, how do you design it without agreement among a committee? Just let Google go rogue and define it? And have you ever worked in a large company? Have you seen how difficult it is to get any large group of people to agree on ANYTHING? These specs depend on the agreement of multiple large companies coming together. Each one of those companies is made up of many subcommittees who have to come into agreement with each other.

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.

> For an open standard, how do you design it without agreement among a committee?

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.