To combat this, I propose a new script type: <script type="safe">.
This new type of script can only be declared inline, disallowing linking external scripts. This would fix the “external JS didn’t load” issue because if you got the HTML, you got the inline script.
It would provide enough power to enable Web Components but not enough to enable tracking.
Deeply wrong assumption in HTML architecture change discussion. Here we can (and should) discuss the root cause and 'right" ways of solving the problem. Given list of challenges exposes the lack of declarative behavior definition for given cases. Those have to be addressed on per-use-case basis.
Special kind of JS would not solve the problems, it just would mask it.
I think such a restricted API could be created with the forthcoming Realms mechanism.
Creating such a safe web API subset seems incredibly difficult. I wouldn’t bet on it that it’s possible. The web platform is in such wide use that there will always be websites that will figure out ways to misuse even the “safest” APIs for nefarious purposes, if they’re forced to.
I certainly like the idea of encouraging developers to refrain from having their pages make numerous HTTP requests, which can degrade the experience of users with patchy connections, with pages being partially loaded and stuck in that state.
The idea behind this proposal is to disallow all programmatic network access (like fetch) and all identifying contextual information (like document.cookie and document. location. (User-initiated network requests, like submitting a form by clicking a button, would still work.) This would prevent the isolated script (which would be allowed to run when other scripts aren’t) from pinging tracking servers or adding hidden inputs to a form containing identifying information gathered client-side.
This could mostly be achieved by denying the use of most web APIs. There are a few methods available in the DOM API that would need to be removed, namely canvas.toDataURL(), element.click(), and form.submit(). The DOM API, Intersection Observer, Resize Observer, and Screen Orientation API would provide most of what’s needed for simple UI Web Components and other basic UI and accessibility work.
By denying contextual information and access to cookies and sources of entropy (like canvas.toDataURL()) these scripts would be unable to fingerprint the browser or add tracking information to the page.
Not directly relevant to proposal, but addresses same concern of security via scope insulation and inline scripting.
For Declarative Web Application(DWA) I am imagining the business logic defined declaratively( no js ) and in a manner when there is no cross-scope and global scope overlap between transformation pipelines and scoped elements. That pattern can be propagated into JS and most likely would be available for consumption of DWA patterns from usual JS.