[baroomba]

HTML clients & standards have stagnated badly because we know javascript and heavy-handed CSS can work around any problems—even if those solutions are almost always bad (usually: highly janky, at least).

Example: Table sorting. Hell, maybe table pagination, too.

This is part of why developing HTML-based UI still seems so weird and shitty compared to native, even with the aid of Javascript. Those native SDKs provide way more support for common, basic use cases. Even within the narrow scope of rich document format & display, HTML without Javascript is crippled (see again: super-basic and common table functionality). Plus you'll get a hell of a lot better performance letting C/C++/Rust handle those kinds of basics, rather than trying to re-create them in CSS and Javascript.

Another example: there's a clear, fairly common need for tiled dynamically-loading images, as in maps applications. That should be a tag, and... that's all. Just a tag. To get that whole thing. A couple properties to enable/disable things like zooming. Some sensible standard for how to request tiles by X/Y at a given total canvas size (so, just a convention for image URLs) so that just has to be implemented once per server-side language, and can easily be pre-generated and served from actual files. A way to drop other elements on the image at some X/Y value for pins or linking people's faces to wikipedia entries or whatever, kinda like old school imagemap elements. That's clearly useful even for document-centric usecases (aside from maps, consider, say, ultra-high-res images of painted church ceilings). The browser and HTML should include that.

Search. Complete- or hint-as-you-type search fields should be a built-in element, with results from local or remote (some convention for the URL) markup-based sources.

There's a ton of stuff like that which, in 2020, really ought not require Javascript. Lots of which are still basically rich-document UI elements that've been in demand for 15-25 years at this point, with the holes filled a thousand times over at great cost in person-hours by slow, janky, battery-eating JS and CSS. And that's not even considering overhauling HTML to better suit use in "applications", which could also be done and arguably should be done, since we've pretty much lost the battle to keep that from happening.

I'd love more of the Web to be Javascript-light or -free, but modern HTML standards & clients aren't really up to the task. Mostly because (I think) Javascript has freed them from having to worry about it. "Table sorting by column? Well yes of course everyone wants that basically everywhere all the time, but let Javascript handle it".

[roca]

> tiled dynamically-loading images, as in maps applications. That should be a tag, and... that's all. Just a tag.

You say that, and then you disprove your point by going on to list a bunch of extra features that that tag would have to have. And even with those features, major map sites wouldn't use it because they render map content client-side using vectors, not map tile images, and have lots of other features your tag wouldn't support.

Implementing your vision would mean a massive increase in the API surface of browsers, with concomitant increase in browser bloat, and browser and standards development effort ... while there's a strong argument that browsers are already too complicated.

Even so, when we've tried to implement declarative features on the Web we've seen over and over again that it's impossible to satisfy everyone's needs without scripting. (See e.g. HTML5 form validation, SVG vs canvas, VRML vs WebGL, ...) That is why stuff like the Extensible Web Manifesto emerged.

[baroomba]

I’m pretty sure CSS, JavaScript, and the way both interact with each other and with HTML are the main reasons writing a useful browser engine is rapidly becoming impossible—and we’ll end up replacing it with Wasm rendering to a canvas for most things while not cleaning up HTML to be something simpler and delightfully less-capable, sadly. I think you could significantly increase the richness of just HTML without making it, per se, 1/10 the challenge of implementing all of those together.

[roca]

The interactions between JS, CSS and HTML are not the main problem. The main problems are:

Feature interaction complexity between CSS features is a huge problem. Some of that could have been avoided if CSS had been designed differently, but some of it seems unavoidable (e.g. laying out text with mixed directions, mixed writing modes, ruby, font substitution, modern font features, etc etc --- at speed --- is just really complex).

Modern high-performance JS is really complicated to implement.

The plethora of APIs exposed to JS --- WebXYZ --- is incredibly complicated.

HTML is pretty complicated, e.g. HTML forms.

But if you take away JS, CSS/HTML don't get a whole lot easier, assuming you're still supporting interaction in some way. I mean, for your proposed map API, if the user can manipulate the functionality and you have lots of features that can be customized declaratively, it's not much more complicated to expose those controls to JS.

If you can simplify the problem so that CSS and HTML don't need to support incremental relayout/DOM changes, that would help a lot, but removing JS isn't enough for that. Things like zooming, window resizing, incremental loading, and any kind of editing put a lot of the same requirements on the engine.

[anderspitman]

This is a great point. You definitely couldn't implement every thing with just HTML/CSS. But I think you could do a lot. In some cases you would definitely have to resort to old-school methods like literally paging your content, which isn't ideal, but maybe worth the tradeoffs.