So... I think scripting is actually really important -- otherwise not only are you stuck with the lowest common denominator of all browsers, but the browsers need to implement a billion bug-prone views -- that map view link mentioned? Now you need a map viewer!
What you want is to have scripting with capabilities -- preferably on top of WebAssembly (JS is a sin).
The best part is this improves the experience of noscript users -- rather than nice graphical widgets being broken, instead, they can just run scripts without any "network" capability -- which should forbid the scripts not only from accessing the network, but make it so anything they modify becomes "tainted" and is not allowed to show up on a network call (so e.g. if they encode some data in a form, trying to later submit that form somewhere else on the app will give a warning).
Now -- most people don't care and don't want this. And that's a good thing -- capabilities put the power in the hands of the user agent where they belong.
More interestingly-- capabilities can be shimmed! Rather than "you are not allowed to access my GPS", it should be a first-class feature to feed the WASM a GPS stream of your choice.
> So... I think scripting is actually really important -- otherwise not only are you stuck with the lowest common denominator of all browsers, but the browsers need to implement a billion bug-prone views -- that map view link mentioned? Now you need a map viewer!
In the browser? The map viewer could just be a separate programme entirely, like a PDF viewer, etc. I remember watching rdg (the current main Dillo developer) demonstrating this with a separate map programme.
Most of your post seems to assume this "everything must be in the browser" approach, which is actively not what Dillo is about. (I would know, I use Dillo regularly.) It adheres to the Unix philosophy.
EDIT: Looking at it closely, did I just respond to an LLM post?