Without justifying it, the reason is simple. They are using a front end framework (bootstrap) that many developers use/understand that also supports 99.9% of browsers.
Running a browser without javascript that you still want graphics to display (so not a screenreader or text-based-browser), is part of the .1% they are willing to disappoint.
Do I think it is overkill? Sure. Do I still use jQuery at work even though the vast majority of its once handy features are now baked into JS in the browser by default? Of course.
How do you jump straight from JS to screen reader or text based browser? What happened to HTML+CSS viewer? Isn't reading an RFC the perfect poster child for an activity that ought to consist of viewing a noninteractive document?
It’ll be a run-on effect of whatever framework they are using, and they very justifiably don’t want to bother catering to you. Having JS disabled in 2026 and complaining about sites not behaving is simply a performative act.
2015: It's a SPA blog because my employer forced me to do it that way, I didn't want it.
2026: It's a SPA blog because I very justifiably don't want to bother catering to you. Having JS disabled in 2026 and complaining about sites not behaving is simply a performative act.
Even then, they're using disallow lists. If you go on a random web page with novel JS, then that'll still be run.
The only people working of allow lists are the people running NoScript and the like, and those truly aren't running random JS. But those people are a rounding error compared to the greater internet.
>and they very justifiably don’t want to bother catering to you
Considering they are one of the very few sites and VPNs that allow sign up without JS your claim is verifiably false. They also collaborate with and develop there own tor browser fork which has the highest rate of non JS user.
What "buttons icons"? When I set the "javascript.enabled" preference in Firefox 151 to "false" and reload the page for RFC 5737, I get a "Javascript disabled? Blah blah blah blah." complaint near the top of the page. I do not get
* the useless-to-me "document history" bar graph at the top
* the automatic switch to Dark Mode(TM) that I don't care about
* functional pull down menus at the very tippy top of the page that are entirely unrelated to RFCs that I give zero shits about
The "without javascript" version of the page seems to me to be otherwise identical. Amusingly, the "Email authors", "IPR", & etc buttons switch to the pages they reference notably faster with Javascript disabled.
What broken things were you seeing that I haven't mentioned? Were you using Chrom(e|ium)? Safari?
> I set the "javascript.enabled" preference in Firefox 151 to "false" and reload the page
Do it the other way around - disable javascript first, clear cache/open incognito (maybe close/open browser after that just for good measure), then go to the page.
If you load it with javascript first - buttons icons stay loaded after you disable it.
The only thing that I don't do in Firefox's "Private Browsing" mode is play a handful of stupid little in-browser games that save progress in a cookie or whatever. I even have Firefox set up to open in "Private Browsing" by default. Here's what I did just now:
1) Quit Firefox
2) Opened Firefox
3) Visited 'about:config'
4) Set 'javascript.enabled' to 'false'
5) Quit Firefox
6) Opened Firefox
7) Re-visited 'about:config' and verified that 'javascript.enabled' is still set to 'false'
It's still exactly like I reported it was. The "Manage browsing data" thing accessed through Firefox's regular settings dialog doesn't indicate that there is any data saved by any ietf.org subdomain, and when I watch the Network pane, a ctrl+shift+f5 reload of the RFC5737 page indicates that the page loads everything from an ietf.org subdomain... so the saved resources from one of the like eight domains in that list aren't relevant.
I checked more closely and here is what appears to be missing:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://static.ietf.org/dt/12.65.2/ietf/bootstrap-icons.5b9cac4e.woff. (Reason: CORS request did not succeed). Status code: (null).
Bootstrap icons.
Block javascript - icons won't load.
Allow javascript - icons load.
Block javascript again - icons load, unless tab is closed and then opened again.
This behavior has been observed previously.
I tried to selectively block css to see how it's tied to javascript.
Block javascript, block css from static.ietf.org - icons won't load, page layout is broken.
Allow javascript, block css from static.ietf.org - the icons won't load, layout is fine.
Evidently, with javascript blocked, layout css loads fine, but bootstrap icons only able to load when javascript is not blocked.
'javascript.enabled' setting seem to has no effect on icons. However, unlike NoScript, it does not provide any domain separation/granularity.
Running a browser without javascript that you still want graphics to display (so not a screenreader or text-based-browser), is part of the .1% they are willing to disappoint.
Do I think it is overkill? Sure. Do I still use jQuery at work even though the vast majority of its once handy features are now baked into JS in the browser by default? Of course.