Consider supporting JavaScript disabled by browser

Since discovering this proposal, I've been following it closely. I've been excitingly following its updates since.

The purpose of this issue is to draw attention to the case of JavaScript being disabled in the browser. When disabled in browser, the <script> tag is not parsed at all.

This means features such as routemap, if <script type=routemap> will be the final implementation of it, will not work in these browsers. For fragments, if <script type="fragment" src="fragment.html"> were the chosen implementation, same thing.

It would be very unfortunate if a large set of the features gained by this proposal of updates were locked behind the browser needing JavaScript enabled. For a practical example, the TOR Browser is an example of where this use case would be mostly encountered (it will take a while for Firefox to implement these after Chrome, but they will trickle down to the TOR Browser eventually). Beyond that, though, it feels incredibly wrong to lock a large set of these features behind needing JavaScript enabled.

To me, it feels incredibly wrong to add supposed additions to HTML/CSS that in actuality are locked behind JavaScript, even if not explicitly used by the webpage. HTML patching and fragments should remain HTML features. CSS route matching (and view transitions, though that's in another repo) should remain CSS features.

Take this statement for instance in the route-matching-explainer.md:
By providing a patchSource to a rule or set of rules, which is a URL or a serviceWorker (exact semantics TBD), updating the document is performed by the browser, without interaction-time javascript.

While technically true, it still DOES require JavaScript (enabled in the browser).
I thought I had read other statements in other articles about features from this repo about not needing JavaScript, but I'm unable to find them at this time.

When I write code for the web, I always make sure to support the case of JavaScript being disabled. Far too many websites take it for granted nowadays, some even too much (RAM is expensive nowadays!). For me, my code is not complete if they will not work without JavaScript. If I were to write code that made use of the features of this repo and they required JavaScript, I would either choose to not use these entirely, or I would have to write a separate fallback option that would have to be maintained. It would be nice if new features of HTML/CSS would work without JavaScript being assumed enabled.

TLDR: as much as it is possible, please consider supporting JavaScript being disabled browser. It's incredibly frustrating when an exciting feature comes out that either inevitably is locked behind JavaScript, or subtly requires JavaScript by presenting itself as HTML/CSS but instead being JavaScript wrapped in an HTML or CSS cloak as a disguise.

Start by reading route-matching-explainer.md and the issue's examples of script-based route maps and fragments. Define whether the proposal can support browsers with JavaScript disabled, document the resulting requirements or limitations, and resolve the issue with an explicit design decision.