[pbronez]

I agree. The reason it seems like web standards are always “behind where we should be by now” is mostly a coordination problem, with some prognostication error. To work seamlessly, we have to agree on what the standard should be and implement it well, broadly, and consistently. That’s always going to be slow and patchy.

I don’t think it’s possible to anticipate exactly how everyone will want to use everything, but maybe we could reach a world where it’s easier to iterate on this.

For example, what if there was a way for the community to implement new HTML tags for their preferred browser? This could be implemented as an extension, though perhaps not under the dominant WebExtension paradigm. This would allow much faster iteration on the semantics of HTML within the secure sandbox provided by the browser. The IPFS extensions are a nice example of doing this at the protocol level.

Similarly, what if you could version HTML tags? That would be a bit of a nightmare, but would also allow authors to communicate more information to the browser about what functionality is expected from the tag.

Of course, this would lead to a strange ecosystem with many dependency management headaches for users. You’d have to worry about what new features were needed by the page you’re trying to view, which extensions you have installed, do they implement the tags you need, and do they do it well?

This would lead to “super extensions” that address many tags and become de facto requirements for everyone. Then those become security targets. Of course, they would have their own coordination process, parallel to W3C. This would become a business target just like W3C is, with google trying to manipulate it to liquidate user freedom to support advertising.

It’s hard to get big groups of people to work together effectively.

[wruza]

Strangely “we” can do that for linux, but cannot for the web. “apt install myapp” pulls the required trusted binary dependencies, if they aren’t there, and that’s it. Qt, wx, gtk, ffmpeg, mesa, you name it. Potentially malicious code is reviewed by distros and is not included, so if you want to distribute libhacky with your myapp, the entire ecosystem has to accept it before a user could trust it. But browsers are somehow different. I think the main reason is that browser vendors want their control over the market, and the entire issue is not technical/community at all.

It’s hard to get big groups of people to work together effectively.

One of the valid ways to deal with it is to let them work separately.

[shadowgovt]

It doesn't work nearly as well in Linux as we'd want to impose such a design on the web.

"apt install myapp" works 95-99% of the time. The remaining time, you drop yourself into DLL hell of some flavor or other (package was poorly maintained, or your clone of the package repo indices is out of date, or you installed a local copy built-from-scratch of one of the binaries and it's now fighting with the distro binary, &c &c). And then remote tech support is impossible because for someone to provide support, they either need intimate knowledge of your configuration or you need to be running a stock configuration (and with very few, usually vendor-controlled exceptions, "stock configuration of a Linux distro" is a non-concept).

There was, ages ago, a paper describing what the design of a componentized browser rendering engine would look like (where pages could basically declare "I require engine components X, Y, Z" and the browser would have a library of them that could be spun up on a page-by-page basis). I wish I could grab a link to it; I think it may have been a Mozilla experiment? If I recall correctly, the complexity meant it never gained traction.