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)

▲

dimal 4 months ago | parent [-]

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.

▲

prmph 4 months ago | parent [-]

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.

▲

dimal 4 months ago | parent [-]

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.

	▲	prmph 4 months ago \| parent [-]
		> 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.