Great start. Although I think we need to reverse the trend of Chrome becoming the single browser web developers use. The amount of sites that unnecessarily[0] work only in Chrome is growing daily. And that's not even counting browser extensions. I think this, more than anything else, will determine if Chrome becomes the "Internet Explorer"[1] of this decade or not.
Skipping testing in IE is one thing. Skipping testing in Firefox is a sin.
[0] Unnecessarily, because cross-browser compatibility isn't hard, simply include CSS prefixes besides -webkit and use standardized JS APIs.
[1] Internet Explorer, a term for a closed-source browser that creates non-standard APIs that developers jump on, forcing either users to use that browser, or other browsers to implement the non-standard APIs too.
The thing about "Internet Explorer", is that using IE Edge, I often run into websites that demand I "Upgrade" to Chrome and won't let me use them.
Fudging the user agent however, allows that website to work perfectly fine.
Not testing in IE is one thing. Presenting an nonintrusive message warning you don't test in IE is another. Paying money to advertise your website, then, when I click your link, greeting me with a condescending "IE Users are idiots" type message that doesn't let me proceed, doesn't make me buy your product.
For a few months now, Bank of America's site has been including a giant alert at the top suggesting that I use a supported browser, such as Firefox, Chrome, or IE. ... Except I'm already using Firefox. I'm not customizing the user agent or anything.
The dumbest user agent based browser detection mechanism I ever encountered was one that a major grocery store chain had in place on their website. At the time, I was running Linux on a desktop computer which had an ARMv7 processor.
I visited their website and was, like in a lot of cases where they assume ARMv7 means I must be using a mobile device, redirected to the mobile site.
That's not the stupid part, though (just annoying). These guys took it one step further and had their mobile website decide that I was in fact not on mobile, and then they proceeded to throw me into a redirect loop between the desktop and mobile site. Talk about messing up with browser detection.
I wrote an e-mail to report the issue to the people in charge of the site, and you know what they tell me? Oh, "we forwarded your message to our web developers but they said that this doesn't happen". Wow, ok, "this doesn't happen". Guess I must be hallucinating, then? Well, jokes on them 'cause if they hire people who break their website so that I can't check the opening hours, guess where I'll be shopping? Not at their store, that's for sure.
Add this to the fact that Edge is still the only browser on Windows that's suitable for use on a device with a touchscreen, and it's downright insulting.
I have Chrome on my Surface. I choose to use Edge instead because Chrome is unusable without my Type Cover plugged in, and I'm not doing that while laying on the couch.
Hey Google, want me to use Chrome on my Surface? Then give me the Android version of Chrome running in a container. Phone UI, please.
If you ask me, insulting is having a desktop OS pretending to also work on tablets and releasing that to consumers. You can't blame companies for not releasing apps that can work in tablet mode. It takes time, because that's basically like developing for a whole new OS. And Microsoft could do it because they are the ones developing the freaking OS.
I very specifically got my Surface for a road trip where I needed a device that would be a fully-functional laptop in my hotel room but would be comfortable for reading comic books (and other things) on while sitting in the back seat of a car for hours on end.
Windows tablets were my only option. An Android tablet (or an iPad) might work fine in the car, but it would make a terrible laptop in the hotel room, and a conventional laptop would be unusable in the car.
After my road trip, my Surface found continued use as my couch computer, effectively replacing my phone. Honestly, as long as I have a web browser that works I don't need much else. Edge works; it might be more minimalistic than I like, but the vast majority of what I want to do with a computer on my couch is satisfied by Edge. Oh, and the Facebook app for Windows 10 is awesome. It's everything I've wanted out of the Android app, which has been a constant disappointment for me.
Intuit doesn't seem to do this anymore, though they definitely did for years. I've used mint, quick books online, and TurboTax on chrome and Firefox on Linux without issue.
It shouldn't matter what browser you're using, that's the point of having web standards. I can understand not wanting to support certain users that use whatever browser you don't want to support, but a visible, non-intrusive and dismissible warning at the top should be enough. Otherwise, making radical decisions based on the User-Agent defeats the whole point of having web standards.
To be fair, that notification is for the benefit of the everyone. Users are too lazy/ignorant to switch browsers. The notification pushes them over the edge and prompts them to switch. They get a more secure and overall better browser.
On the other side, developers can spend more time developing features instead of fixing IE compatibility bugs.
The notification pushes them over the edge and prompts them to switch.
Pun intended? But seriously, whenever I see one of these browser-blockers (and it seems Opera gets hit too), I just leave the site and never come back. Chances are, your site is not unique and I'll find what I need somewhere else.
developers can spend more time developing features
IMHO, those are "features" which no one really cares about. Stop messing around with fancy CSS and JS, spend the time developing a simple site that almost naturally works in IE too.
> IMHO, those are "features" which no one really cares about. Stop messing around with fancy CSS and JS, spend the time developing a simple site that almost naturally works in IE too.
I agree that targeting of Edge browsers is ridiculous since it's keep current, on the other hand for IE and if the site is non-commercial/personal (commercial sites should really try to be compatible on as many browsers as they can) I don't really blame them if they're wanting to use modern web standards. Microsoft has abandoned feature updates to IE, and sadly only made Edge available to W10 users.
Flexbox in CSS is one example. It was made to simplify the creation of page layouts and content flow and includes various features that were sought-after for a long-time that require hacky or more complex solutions otherwise. The majority of its bugs, or just plain missing features are found in IE10-11 (and absent completely in earlier versions). Either creators design the site to entirely compensate for IE and loose that flexibility (pun not intended), find some Javascript polyfill that actually works/fixes such bugs, or just present some message to users for unsupported browsers (not that it needs to necessarily block the page though). It's just one of several useful features that make things far easier but lacks full/partial/any support in IE.
It's really not. If developers would code to the standards with minimal tweaks there's absolutely no reason someone couldn't write a site without those spammy notifications to downgrade to chrome.
So much this. While on Firefox, Google only pulls that on you once, they constantly reoffer it to Edge users on a nearly weekly basis. And recently, they actually made the bar bigger and more obtrusive.
I filed an issue on the Chromium bug tracker, they assigned someone to look into it, and of course, nothing has been said since.
> While on Firefox, Google only pulls that on you once
To this day, and for years, I continue to receive these messages from Google sites informing me to upgrade to Chrome. I've even had them pop-up on Chromium.
I am pretty sure the only way to send feedback to the Chrome team, other than the Chromium bug tracker (which is pretty much the same people), is to send feedback from within Chrome.
Obviously, I don't have Chrome, since my issue is them pestering me to install Chrome. Which I'm not going to do.
On the other hand, if Google wants to prevent their reputation from sinking to the level of "install the Ask Toolbar", one of the Googlers on the Chromium bug tracker will see that it is dealt with.
Just to clarify, the product you should be reporting this on is Google Search, or whatever site you're trying to use the browser on that's giving you the annoying reminder. Not the browser itself.
I work on Firefox compatability for a major website, and while obviously I agree that we need to stop building websites that only work in Chrome, it isn't always as easy as you suggest.
A large web app is almost guaranteed to run into one of Firefox's many long-open bugs. But the biggest reason in my experience is performance. Gecko's rendering engine is poorly-optimized, to the point where I regularly see a DOM modification take 10ms in Chrome (easily within a single frame) and 1000ms in Firefox (locks the UI and causes the page to flash white).
If you can isolate that DOM performance bottleneck or point me to a live example, I'm happy to pare it down to a minimal test case and make sure it gets fixed.
(We have some enormous architectural changes inbound which should help, but I'd still love to make sure we have a test to prevent regressing)
In Chrome it's buttery smooth on any decent computer made in the past 5 or 6 years. In Firefox it's usable on a powerful computer, but notably worse than Chrome.
On an under powered laptop Chrome is still very usable, not quite 60fps, but probably 30-40fps on moderately complex designs.
Firefox is a choppy mess on low end hardware.
This is a recurring issue with Firefox. It's just ok for regular web browsing, and it's a hot mess for any web app that needs to do any moderately taxing DOM manipulation.
As much as I love Firefox, it's just leagues behind Chrome in regard to performance.
I agree completely, I only use Chrome and only open FF when I'm about to push a feature or if QA kicks something back. In the same way I don't use a production size DB locally when writing new code (but need to test performance after the feature is complete) I don't use a slower browser in my day to day development because why would I? It would be like given the choice between two computers to work on choosing the slower of the two.
Slightly tangential, but on the topic of browser extensions: the Chrome extension API served as the basis for Mozilla's somewhat recent Web Extension API [0]. Many, if not most, Chrome extensions can run in Firefox out of the box right now (there's even a Firefox extension that lets you install these from the Chrome Store [1]). This has been an incredible development for anybody doing cross browser extension development (which has otherwise been a fair bit more complicated than simply including "CSS prefixes besides -webkit").
Having different browsers compete on things like this and then having the better technology become standardized and implemented in multiple browsers seems like a fairly positive outcome.
"Web Extension API" is exactly the issue at stake here. Chrome develops a new API for extensions. Everyone jumps on it. Firefox abandons it's powerful (although insecure) extension API, and re-writes it to follow Chrome's. There's a lot of marketing-speak around the reasons FF did that, but it really boils down to: Chrome is winning in the extension ecosystem, let's make them all compatible with FF too. At the loss of the entire existing extension catalog.
Firefox's extension system was powerful but there was next to no chance that XUL based UI was ever going to be adopted in the other major browsers. I'm sure that tapping in to the Chrome extension ecosystem was a big factor in the decision but I would argue that the Chrome extension API was also a far better suited candidate for cross browser standardization.
Firefox's extension system was arguably too powerful. Back when I ran Firefox, I regularly ran into extensions that conflicted because they monkeypatched the same parts of the browser UI.
Firefox intends to keep many of the powerful feature in its version of the extension API. The previous API was powerful because it let addons reach in to the guts of Firefox's UI and tweak whatever they wanted. This meant that some parts of the browser were frozen from being changed, and extensions broke every release. There was no public-private distinction. It seems like the plan is to add most of the capabilities that were used by the old addons in the new API, so most of the useful Firefox-only addons should still work.
Skipping testing in IE is one thing. Skipping testing in Firefox is a sin.
[0] Unnecessarily, because cross-browser compatibility isn't hard, simply include CSS prefixes besides -webkit and use standardized JS APIs.
[1] Internet Explorer, a term for a closed-source browser that creates non-standard APIs that developers jump on, forcing either users to use that browser, or other browsers to implement the non-standard APIs too.