which is the blog post, rather than a list of exit servers
related to this post: https://news.ycombinator.com/item?id=48143880
which is the blog post, rather than a list of exit servers
related to this post: https://news.ycombinator.com/item?id=48143880
How does that matter? The point isn't that the reader should know that "oh, this is a reserved address". The point is that there should be no room for the address that's actually being used by someone to end up being used incorrectly just because it showed up in some random documentation.
Much like how you probably wouldn't be thrilled if your phone number was used as an example in some random documentation somewhere.
Mmm.
It's pretty easy to put three IPv4 /24s on a sticky note on your monitor. I think it's not unfair to say that if one can remember every fact related to one's job, then one has a job with a very, very small scope.
Also, this is another great reason to use IPv6. The v6 documentation prefix is '2001:db8::/32'... plenty of space for example subnets and easy to remember.
It partly because attitudes like that is why software is a mess. Too few people care about correct semantics, everyone is satisfied with whatever sticks. From lists for sets, to tag soup instead of markup, and so on - all the way to modern code slop.
</rant>
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.
S in https stands for "script". /s
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.
Within a rounding error, 100% of people on the internet.
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.
Anything SVG does maliciously, it does by containing JavaScript, so SVG's worst case is a subset of JS's.
how???
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.
* 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?
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.
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'
8) Visited <https://datatracker.ietf.org/doc/rfc5737/>
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 use NoScript, not 'javascript.enabled' setting.
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.