My previous response to similar concerns is relevant. To elaborate:
If nothing prevents bad behavior from an ISP, and it has happened before, then you should assume it’s happening. This extends to injecting JavaScript apps into insecure connections.
Unless you trust every hop from your browser to the destination server (and back), assume anything unencrypted can and will be inspected (and potentially tampered with). Encrypt everything you can.
For CSS Naked Day, I decided to do something a little different. I didn’t want to actually disable my stylesheet: very long lines of small text aren’t terribly accessible, and fingerprinting-averse readers of my Onion site may not wish to zoom in (I know for a fact that these people exist; I’ve spoken to them, and I don’t like reducing my readers to numbers in an analytics dashboard).
Instead, I made CSS Naked Day participation opt-in with a new a query parameter to the URLs: Just add ?sandbox=broken to the end of any URL on seirdy.one. This query parameter sets a maximally-restrictive Content-Security-Policy header, instructing your browser to block CSS, images, media, and more from loading. The only thing that the CSP will allow is submitting forms (Webmentions). See my CSP Bug Reproduction page for other values you can give the sandbox parameter on seirdy.one and its Onion location.
This does not apply to mirrors of my site, such as the envs.net mirror.