Let me guess your testing workflow:
Write code in VS Code
Open Chrome DevTools
Check if it works
Ship it
You just broke Firefox.
And Safari. A...
For further actions, you may consider blocking this person and/or reporting abuse
This is less about Firefox and more about architectural discipline.
When we test only in Chrome, we implicitly bind the product to one implementation. That coupling is rarely intentional, but it’s very real. Firefox and Safari don’t “break” things — they reveal assumptions that Chrome happens to tolerate.
Cross-browser testing isn’t about market share or ideology. It’s a validation step: does the system behave correctly according to the contract, or does it merely work because the runtime is permissive?
From experience, issues caught in a second engine are almost never edge cases. They’re signals. Ignoring them just pushes the cost to production, where users become your QA.
This isn’t a browser problem. It’s a systems problem.
Firefox doesn't break things, but Apple surely does. Safari has no alternative on iOS, and older iPhones get stuck with outdated software which is why some developers said that "Safari is the new Internet Explorer" and that's true in a way.
I rarely had any Firefox issues in recent years, but iPhones are an issue. BrowserStack is super useful, but a real device is a helpful addition to get the real feeling, not just resized remote control with a mouse cheating option.
I agree that Safari on iOS is a uniquely hard constraint — especially with engine lock-in and long-tail OS versions. That pain is very real.
But I’d still frame it the same way: Safari doesn’t create the problem, it exposes it. When a platform forces stricter behavior (older APIs, missing features, tighter limits), it acts like a stress test for assumptions we didn’t formalize.
That’s why I’m less interested in which browser breaks and more in why it breaks. If a system only works under the most permissive runtime, that’s usually a contract problem, not a tooling one.
Real devices absolutely matter — not to “support Safari”, but to validate that our architecture degrades predictably when the environment is less forgiving. That’s the signal worth listening to.
Clean code, progressive enhancement and graceful fallbacks are a good practice, I agree. Outdated browsers, however, are not just "stricter" - I wish they were - but partially buggy or using early, experimental implementations of later standards, like Microsoft's grid implementation, Firefox masonry layout, or iOS Safari's vh calculation which lead to the introduction of dvh as yet another new feature not supported by every real device out there.
I agree that many issues that seem edge cases first are actually signals helping to discover serious issues. In this respect, we should even thank Apple for the challenge.
That’s a very fair distinction — and I agree with you here.
You’re right: many issues we hit in older or constrained environments are not about “strictness” in the ideal, spec-pure sense. They’re often about incomplete, buggy, or transitional implementations of standards that evolved over time. Safari’s vh → dvh saga is a perfect example: not stricter, just different and fragmented across real devices.
But that actually reinforces the same underlying point for me.
Whether the cause is strictness, partial support, or historical quirks, the effect is the same:
these environments surface assumptions we didn’t explicitly model.
When layout math, viewport logic, or feature availability subtly differs, the question becomes:
did we define the contract of our system clearly enough?
did we decide what must hold true vs. what can degrade?
In that sense, I agree with your last line a lot — these are signals. Painful ones, sometimes unfair ones, but still signals. They force us to think in terms of capabilities, fallbacks, and invariants, instead of “this happens to work on my machine.”
So yes — sometimes we curse Apple 😄
But we also end up with more resilient systems because of it.
That’s why I see these issues less as browser wars and more as stress tests for architectural clarity.
This is such a basic requirement of Frontend, it's really quite shocking. It means poor hiring, poor QA, poor leadership. I could go on and on.
The underlying engine, WebKit, is well supported on Linux (mostly thanks to Igalia) so if you want to test on Safari, but don't have any Apple device, try Epiphany (aka GNOME Web) (and soon also Orion). Should work even on Windows under WSL2.
In my opinion, some other browsers (cough cough opera cough cough) don't get enough attention, and just get skipped over when testing. (It almost led to me failing a Spanish assignment because the course didn't account for Opera, you know, EXISTING.) In my opinion, browsers should adhere strictly to w3c so that stuff, you know, works. I had to spend FOUR HOURS debugging my site for ios devices, and I had no idea what I was doing wrong because I can't afford a Mac. If Apple had ATTEMPTED to adhere to the STANDARD, than I wouldn't have had to waste four hours of my life pushing broken production builds to fix everything. WHY DO COMPANIES JUST ASSUME THAT PEOPLE WILL JUST ADHERE TO THEIR "STANDARDS" AND NOT CARE ABOUT THE ACTUAL STANDARDS THAT THEY SHOULD'VE ACCOUNTED FOR IN THE FIRST PLACE?!? (Thank you for reading my badly written rant.)
(For context, I use Opera GX as my daily driver browser, it just works a bit better for me.)
Nice rant.
You're right, but unless you have a specific audience (check your analytics) graceful degradation seems acceptable.
Of course, if the website is broken or basic features simply do not work, you have a big problem.
Good
That's great!!!