Chrome is the new Internet Explorer: companies and developers lazily optimize for it, and users (and developers) suffer the consequences.
Also,
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
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.
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.
if you push out some purist code that is "supposed" to work to some spec, but it doesn't work... you have to start making decisions about which path forward to take.
outside pure code, you still have to deal with testing/verifying/confirming, then committing to that for each version of the browser on multiple platforms.
Providing actual strong positive and ongoing support for your system on specific browsers and platforms is generally better than "well... we wrote to the published spec, the problem is every browser vendor sucks and they need to conform to my understanding of specs". That ain't gonna happen.
To be clear, I don't think most companies actually put a lot of effort behind their 'support' of just one browser (years ago when it was IE, now when it's chrome).
And it's up to the individual site author whether retaining that last chunk of Firefox-only (or Edge-only, or Safari-only) users is worth the cash outlay to test on those platforms. I've done multi-browser development; it adds significant friction to the process, especially if one's testing infrastructure is rocky (and most are, and it costs resources to do better than rocky).
If the Chrome hegemony breaks down, another hegemony will take its place.
The key idea is: the system favors hegemony for someone. The incentives are
1. Most web developers are trying to maximize number of people who can see their site
2. Some browser (barring lock-ins) will have the plurality of users
3. Developers seeking to minimize costs will target the browser with the most users
4. The browser most developers target will be the one most likely to be able to access the most sites
3 and 4 create a positive feedback loop; outside of other forces, we'd assume a browser with any small margin advantage to asymptotically approach full market control over time.
I can run Chromium on Linux with no layout of cash.
Even if it did run on my phone, I wouldn’t run it, because Google.
Now, on the one hand, this is just me being an annoying, Apple fanboy, tracking-resistant outlier. But on the other hand, “you” targeted the web BECAUSE it’s the open platform for the widest range of users. “You” decided against a native app so as to cut costs and produce a more consistent/responsive cross-platform application. “You’ve” already saved the money it would have cost you to support multiple OSs. Use some of that saving to support the web.
Or don't. I don't get mad when people write bash-specific scripts that won't work on all POSIX compliant shells. This seems analogous (though admittedly non-compliance to web standards has a larger impact than non-compliance to shell standards). Perhaps Chrome removed enough barriers for the tool to exist at all.
Edit: Everybody below is right - I'm thinking only of the version they let stagnate. It as relatively good early on.
Do you see a recognisable pattern here? Do you get a sense of deja vu?
Given IE's install base (essentially every system with Windows, which means greater than 90 or 95% of computer users at one point), it made sense to skip support for other browsers.
MSIE 6's main problem was the stagnation, but that came later. Well, that, and that ActiveX crap.
But if you were on a Mac or Linux system... you had some issues. Mac IE was not the same as Windows IE, and Linux didn't have one.
So Chrome at least is on more platforms.
IE 6 in 2006 (when IE 7 released) wasn't good.
IE6 was great -- it was not without issue but those were minor compared to the problems with other browsers. However, Microsoft just immediately stopped working on it and it would be 5 years before Microsoft released IE7.