I accept that sites can be 'optimised' for use in certain browsers, but a complete lack of functionality is fundamentally anti-web and a sign of sloppy development.
- ed url changed to correct one
Maybe the problem you experienced was not due to a failure on the site designers' part or Firefox but elsewhere; a temporary "glitch" in its delivery to your Firefox browser, one of your browser extensions mucking it up, etc.
I don't encounter sites that don't work in Firefox but a lot of that probably has to do with my browsing tendencies.
Ultimately - it was a list of entries from a database. There's no real reason they should've been caught out by some inter-Browser Gotcha!
There's no real reason, but there is a reason. And part of the 5 why's analysis will show that the developer doesn't test on Firefox, but why should they when less than 1 in 10 users will use Firefox? They'll only make the spend if they have ideological dedication to a poly-culture of browsers or they are incentivized to capture the subset of the last 10% of potential users who can't see their way to switching to Chrome (for even one website).
The reason should be that developers develop along as simple and as standardised a means as they can, so that what they're working on will be consumable by as many people now, and in future as they can be.
Sure, I'm of the 0.001% of people on the planet that could easily spend a half hour going through the console and working out why on Earth their content isn't displaying to me… but this is a .org (.uk) - their remit is to be open and to Do The Right Thing.
Almost 100% of their users are not the sort that should be expected to dissect their website to work out where they've gone wrong.
Again, this isn't anything complicated - it should just be HTML spat out. That's it. Nothing fancy.
Sure, if you want to do fancy rendering shit after the matter, go crazy - but HTML should be just HTML, boring Hx tags and all.
Just read this back - not challenging, but not wanting to waste HN mindspace on niceties, lol x
The single biggest impedance mismatch is that HTML is still fundamentally a declarative language where the rendering agent is left as an exercise for the reader, while the things people want to do with it make more and more sense as imperative tasks. The declarative approach is a great idea---semantics separated from presentation! Pages load regardless of details of the device loading them!---but it's groaning under the strain of the rendering people want to do with it. The HTML abstraction is far divorced from the end result people want, and in that gap implementation nuances (and errors) creep in.
Had a situation years ago where I was fighting multiple error reports from Firefox users because our UI was unusable. It was a scrolling list of data that used flexgrid to organize the columns (because we can't use <table> tags anymore; that's of course heresy ;) ). Something, somewhere changed in the Firefox implementation, and every scroll operation was triggering a reflow of the whole table (full recomputation of the height of every cell). Chrome? No problem at all. Chrome had some heuristic somewhere in the render engine that could tell the underlying HTML hadn't changed and was short-cutting the reflow calculation.
One could claim it's our fault for using flex grid, but I mean... It's in the standard. Should work right. Not my team's fault Firefox's renderer has a bug that makes it supported but shitty (or that they don't have a testing benchmark shaped like our site to realize their performance had regressed).
We chased that problem for half a week before product management pulled us off of pursuing it, on the calculation that it impacted <10% of our userbase and was way too inside-ball to keep burning company time on it (and in a sense, they were right; one major Firefox revision later, the bug was fixed and performance under Chrome and FF was comparable again).
I'm quite sure it's not part of any standard.