4 ms·

I dunno - I hit a site a week that doesn't work in Firefox. The latest being a list of shows on https://www.bfi.org.uk/ https://www.bfi.org.uk/ that didn't … we

I dunno - I hit a site a week that doesn't work in Firefox. The latest being a list of shows on https://www.bfi.org.uk/ https://www.bfi.org.uk/ that didn't … well, list. Turns out it did fine enough in Chrome. 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

wldcordeiro 6y ago
Almost always the sites that don't work in Firefox tend to do things in Chrome specific ways.
shadowgovt 6y ago
Any idea if the issue in BFI's website is the site or Firefox's implementation of the standard?
- detritus 6y ago
  tbh, i didn't bother opening up the console and checking as I was a bit busy at the time and, bluntly - why should I? But I did get in touch to let them know there was an issue. 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!
  - shadowgovt 6y ago
    Yep, and now we can see why developers end up putting "Best viewed with Chrome" on their pages; it's easier than handling bug reports from a userbase that won't open the console (nor should the users be expected to, but that's the space we live in). 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).
    - detritus 6y ago
      All this has happened before, and will happen again. 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.
      - shadowgovt 6y ago
        If there's one thing I've learned from 1+ decades of web development, it's that very few things aren't fancy. ;)
        detritus 6y ago
        Can you expand on this? I've been on/off making websites since '99 and I think have a moderate understanding of the landscapes past and present - I don't see what should be complicated in spitting out HTML onto a webpage. 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
        shadowgovt 6y ago
        It really depends on what you want to do, but to a first approximation (speaking very broadly and without much attention to detail)... Most things that would be considered "web apps" or even "web site development" require a lot of thought. 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).
extra88 6y ago
Visiting the BFI site now, it looks the same in Firefox and Chrome. 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.

wldcordeiro 6y ago

Almost always the sites that don't work in Firefox tend to do things in Chrome specific ways.

shadowgovt 6y ago

Any idea if the issue in BFI's website is the site or Firefox's implementation of the standard?

detritus 6y ago
tbh, i didn't bother opening up the console and checking as I was a bit busy at the time and, bluntly - why should I? But I did get in touch to let them know there was an issue. 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!
- shadowgovt 6y ago
  Yep, and now we can see why developers end up putting "Best viewed with Chrome" on their pages; it's easier than handling bug reports from a userbase that won't open the console (nor should the users be expected to, but that's the space we live in). 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).
  - detritus 6y ago
    All this has happened before, and will happen again. 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.
    - shadowgovt 6y ago
      If there's one thing I've learned from 1+ decades of web development, it's that very few things aren't fancy. ;)
      - detritus 6y ago
        Can you expand on this? I've been on/off making websites since '99 and I think have a moderate understanding of the landscapes past and present - I don't see what should be complicated in spitting out HTML onto a webpage. 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
        shadowgovt 6y ago
        It really depends on what you want to do, but to a first approximation (speaking very broadly and without much attention to detail)... Most things that would be considered "web apps" or even "web site development" require a lot of thought. 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).

extra88 6y ago

Visiting the BFI site now, it looks the same in Firefox and Chrome. 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.