That’s odd. Are there standards in iOS Safari that macOS Safari doesn’t support, or that Firefox doesn’t support? It seems that if you have iOS in your user base, you couldn’t do Chrome only stuff anyway.
For the longest time, government websites in Iran required using Internet Explorer to access. A few years ago, it started to change. Now most of them refuse to work with anything but Chrome. At least in this sense, Chrome is really the new IE.
And no, it's not because there is a standard Firefox does not support. I have installed a user agent switcher add-on on Firefox and that has been sufficient to let me use them. Like back in the days of IE, web developers do not care about users of non-dominant browsers to bother testing on them, and prefer to block them from access instead of risking receiving the occasional bug report or complaint from someone on Firefox or Safari.
Nobody writes to the standard, because no browser is strict about only accepting standards-compliant code.
Personal experience—there are a raft of minor differences between Chrome and Firefox, just to pick two. For example, they parse SVG paths differently. The exact behavior of <audio> tags when starting and stopping them used to be different (don’t know if it’s fixed). There are a bunch of other minor things. I have many times discovered that my app doesn’t work in Firefox if I’ve been developing in Chrome, or vice versa.
If you write a lot of weird code, you can easily end up with broken features or a blank app and stack trace after switching browsers. Of course, 95% of the time it will work fine.
And to turn the question on its head: if a team has finite resources and can only get their site matching intended behavior 100% in one browser, obviously the right choice is one with dominant market-share, not sub-10% market-share, if the goal is to maximize number of people who can see the site.
I tried it on Firefox and Chrome, it appeared to look and work exactly the same with both browsers, at least for the limited use I made of it. I think karatinversion has it right, they just mean they didn't test other browsers.
"Works best on Chrome" rolls off the tongue more easily than "I've only tested this in Chrome; It probably works fine in other browsers too, but your mileage may vary and I don't really have time to help you if it doesn't"!
The platform is the web, not the browsers themselves. The web is an open platform, while some browser push for proprietary features. This is not like Windows vs Linux where each of those OSes are separate platforms, and supporting both can be difficult.
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).
If the platform is the web, but a standards-compliant site can work in Chrome but not Firefox, the issue isn't standards compliance.
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).
Spellchecker misfire. I'd mean to say "not an issue of lazy". As a sole developer of some commercial apps, I have often said "This is an IE app" or "This is a Chrome app". The business user of the app gets no added benefit from potentially twice the price of development to have it be cross-browser.
MSIE also implemented some of the standards completely opposite of how they were described in the standards. So making something work with MSIE wasn't just about features it had, but the hassle of making two versions: one to deal with IE's bugs and the other for everyone else.
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.
"In 1998 the Web Standards Project compiled a list of IE's many CSS failings, including this one. Every browser had CSS bugs, however, so this wasn't particularly bad. They made a similar list for Opera and declined to make a list for Firefox's ancestor Netscape claiming that 'trying to list the important bugs would be an exercise in writing long documents'."
It was the most popular because people had to download the others themselves. It was also non-standard, so you often had to make a choice: whether to expend resources to build it for IE because it is most popular and not not worry about the rest, or "do the right thing" and use standards and then write more code to support IE as well.
I was a dedicated Netscape user so it pains me to say it, but MSIE 6 was great when it launched, and Netscape was bloating up, unstable, and had its own range of proprietary extensions (anyone remember Netscape's DHTML...).
MSIE 6's main problem was the stagnation, but that came later. Well, that, and that ActiveX crap.
Nah, IE on Windows was the best browser around for a while. People wrote stuff that only worked on it cause it had the most stuff to target. Remember the debacle that was Netscape trying to come out with anything newer than Navigator 4?
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.
When IE5 for Mac was released 20 years ago, it was the best web browser, period. But it was the last version Microsoft made for Mac, IE6 was Windows-only. While IE6 might have been better overall than IE5 on either platform, IE stagnated, Apple made their own browser to supplant IE5, and Mozilla created Firefox to replace Netscape (and there was Opera which never had much market share but was still influential on other browsers).
Internet Explorer was always faster, smaller, and more stable than Netscape Navigator. By IE3 it was a perfectly reasonable replacement for Netscape (and you had to download it yourself). IE4 got bloated with all the Windows integration but was still faster, smaller, and more stable.
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.
If you've got some spare change to contribute… Browserlist -a tool for developers to target multiple browsers for compatibility– is in need of donations:
Most browsers are based on Chrome/Blink or at the very least WebKit now. Even Microsoft have thrown in the towel for the better as the new Edge is awesome. The only outlier nowadays is really Firefox/Gecko but they do a good job of keeping to standard, it's rare to find a site that doesn't work with it.
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/ 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.
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!
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).
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.
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
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).
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.
And I do think that using their market share to push "standards" no-one else agreed on is what actually makes them the new MS/IE.
Should Firefox just catch upon what Chrome already has implemented or should the standards be decided by a standard body? You can believe the first one is true, I do not.
IE was free as well, didn't prevent it from turning into a pile of garbage when it controlled like 90% market share, which in turn affected everyone (consumers, developers, etc..)
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.
Hypothesis: this will always be true. Standards compliance doesn't guarantee implementation compatibility (because the standards basically never include implementation details or benchmark guarantees), so there will always be cost associated with full browser compatibility in the margins of feature interaction (especially for complicated sites).
If the Chrome hegemony breaks down, another hegemony will take its place.
I think it might not have been true if Mozilla hadn't been so poorly managed and sent Firefox on quixotic adventures instead of making it a better browser, without constant feature regressions and bugs involving global, privacy-compromising outages:
I can imagine an alternate universe in which the hegemony favors Firefox.
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 really want my app to function in Firefox. I've done everything in my power to circumvent it but it's impossible before they fix it. What else can I do? Apparently it's not enough considering the downvotes.
School kids learning remotely are being forced to use Chrome as well. This morning, my child had to switch from Safari to Chrome to use very commonly used site https://web.seesaw.me/
I'm concerned about this. Google is eating up the education market. Not sure if there are alternatives, but my local school board has gone Google for remote learning.
So Google is now spying on children and knows how well they do in school.
There are some legitimate reasons to do this btw. Webspeechapi being one of them.
I've been waiting for so long for FF to support text-to-speech (it does but the quality of voices isn't comparable) and speech-to-text and mdn has some really great documentation about it too but maybe due to lack of GPU or training data they can't add that feature while even Edge has gotten that feature now.
82 comments
[ 3.7 ms ] story [ 137 ms ] threadSome also have the luxury of a production environment that is separate from that environment.
And no, it's not because there is a standard Firefox does not support. I have installed a user agent switcher add-on on Firefox and that has been sufficient to let me use them. Like back in the days of IE, web developers do not care about users of non-dominant browsers to bother testing on them, and prefer to block them from access instead of risking receiving the occasional bug report or complaint from someone on Firefox or Safari.
Personal experience—there are a raft of minor differences between Chrome and Firefox, just to pick two. For example, they parse SVG paths differently. The exact behavior of <audio> tags when starting and stopping them used to be different (don’t know if it’s fixed). There are a bunch of other minor things. I have many times discovered that my app doesn’t work in Firefox if I’ve been developing in Chrome, or vice versa.
If you write a lot of weird code, you can easily end up with broken features or a blank app and stack trace after switching browsers. Of course, 95% of the time it will work fine.
On Safari I get extremely low FPS in general when drawing on layered canvases and sound is not working at all.
It is known that you have to state the recommended screen resolution and the browser version number as well.
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).
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.
https://www.jefftk.com/p/the-revenge-of-the-ie-box-model
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.
https://browserl.ist
Also,
https://www.patreon.com/caniuse
https://opencollective.com/babel
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.
https://css-tricks.com/dont-overthink-flexbox-grids/
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.
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.
If the Chrome hegemony breaks down, another hegemony will take its place.
https://news.ycombinator.com/item?id=19871989
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.
Wolfram Research itself was created in 1987.
You said your app was just slower under Firefox? So it at least "works", no?
https://medium.com/incerto/the-most-intolerant-wins-the-dict...
So Google is now spying on children and knows how well they do in school.
I've been waiting for so long for FF to support text-to-speech (it does but the quality of voices isn't comparable) and speech-to-text and mdn has some really great documentation about it too but maybe due to lack of GPU or training data they can't add that feature while even Edge has gotten that feature now.
https://imgur.com/a/cqb6Dpg
https://imgur.com/a/9xSlKsk