Sadly yeah, we have no control over Foxycart and currently no better option for payment processing. I had hoped it would offer a non-JS flow (and I think it might? check to make sure it's not that Tor browser issue) but yeah, some limitations there I acknowledge.
Even smaller is a bit of JS for the dialogue you get when returning to the page after donating (which you can see by adding #thanks to the url). Again the whole thing is CSS-driven (opening & closing done using the :target pseudoclass rather than any JS) but, because I personally hate when modal dialogues are *only* closeable by their "X" button but not by clicking somewhere outside the dialogue, I added one line of JS to close the modal on background click too (which couldn't, in any way I could figure out, be accomplished with pure CSS except perhaps by some very ugly and markup-heavy trickery).
Collapsable sections would be a useful semantic/accessibility feature to standardize, so browsers could have uniform handling across sites.
This soooooort of exists now in the form of the HTML5 "summary" and "details" tags, though implementation is iffy and it's a long way from being usable for even slightly-complex functionality like our post expanders, sadly. Really that's because "collapsable" isn't especially semantic - many things that are very different in meaning might need to be collapsed in a user interface, and thus there is a "details" tag that does not really apply to "the body of a post".
Some more details for those interested re: the Expand function.
When we built it we considered it very important to make sure it wouldn't just "degrade" but would not be required at all. The native page loads with static "Read More" links that point to the article page as normal; the JS, if executed, replaces those links with "Expand" buttons.
Of course, one of the flaws in the expanders (especially for those loading without JS) is that the full text of all the articles is loaded with the page right now, which is pretty inefficient for the majority of people who don't expand all of them (and completely useless for non-JS users). So we're strongly considering changing it in the future to only load snippets with the page, and request the rest of the post content dynamically on expanding.
You should appreciate the site I built for the Techdirt Survival Fund then :) Aaaaalmost no JS at all, and no reliance on what tiny amount there is (though one small feature doesn't degrade quite as gracefully as it technically could).
That said, I really really really like JS as a language. But I agree that treating simple websites as full-fledged apps running on massive frameworks is stupid and infuriating.
Or, go the opposite way: allow companies to register pretty much whatever they want as potentially identifying marks, but require them to demonstrate actual and substantial customer confusion, with evidence, in order to make any kind of claim against someone else using the same or a similar mark.
How about something asinine drawn out in patent application style, with little figures and text descriptions.
I had been thinking about this general thing, but never really came up with a good specific idea. Also not sure how well I can replicate that technical drawing style - but, it's in the back of my brainstorming mind somewhere!
We tried to make those fields optional and even remove some outright - but for some bizarre reason paypal started rejecting payments that weren't filled out on the foxycart side. As far as we can tell it's an integration issue between the two, and we haven't yet found a way to fix it.
Strange. Our cert seems to be properly covering both www. and non-www. variants in most places, but it's having some trouble on mobile (and with twitter's link-scraper, it seems). Thanks for the heads up - we're trying to get it sorted out, and for now I've added the www. to the other links in the post.