Is Safari really that hard to develop for? Name one feature this site needs that won't run in safari. WebKit has been getting a lot better recently, I feel like not supporting Safari at this point is because of one of three things: you're too lazy to try it, don't have a Mac, or you are stuck to the opinion that Safari is somehow behind Chrome or Firefox in major ways.
I use safari daily and *never* have a problem with a site not working. Ever. So I doubt there's some new web api that this site needs that doesn't work on Safari.
It's been a few years since I did frontend dev, but Safari was _absolutely_ the most difficult browser we had to develop for, _especially_ on iOS.
With IE, you can polyfill missing APIs. With Safari, you have to put in extra work to ensure your polyfills override Safari's built-in implementations in all sorts of exciting ways based on which particular Safari version someone is running, because it's _obnoxiously_ common for Safari to have broken or incomplete implementations of web APIs. So if you're just checking for the presence of some particular global, it'll be there...but it'll be subtly broken in various ways. We had constant issues with Safari's implementations of LocalStorage and IndexedDB, and with its weird tendency to "ghost-hover" over elements after a completely different element in the page was tapped/clicked, and that's just what's off the top of my head from when I last did frontend dev consistently (about 7ish years ago).
The only way to repro any of Safari's weird bugs nonsense, of course, was to shell out for a Mac or iOS device. You can't repro any Safari issues on any other, less-expensive platform. It's classic Oracle-style vendor lock-in with their vertically-walled-off tooling and lack of test images.
Except at least Oracle never put out a constantly-broken browser, let alone one that had -- and still has -- monopoly capture of an entire platform.
If you've got a desktop Firefox or Chrome issue, you can launch Firefox or Chrome on a cheap Linux or Windows machine or VM and repro it, and then snapshot the VM for reproducibility.
If you've got a mobile Firefox or Chrome issue, you can launch Firefox or Chrome on a cheap android device (or emulator), and if for some reason it really truly proves to be something Google or Mozilla hasn't implemented correctly _and_ you can't polyfill it...then you can advise users to try a different browser as a workaround.
There _is no_ "different browser" on iOS. If Apple has screwed up yet another standard web API, your users are hosed unless you can get really creative at dancing around their broken pile of crap.
After switching user agents to Chrome and trying it out, I ran into a problem pretty quick. The dynamically generated "Magic" backgrounds use SVGs with the 'filter: blur' style which isn't working properly despite it being supported by Safari [1]
Most of the features work fine though. Website does state that it's in beta as well.
Someone doesn’t have to have anything against other browsers to prefer using their favorite browser without futzing around with browser-site combinations.
Also, web developers here are interested in any reports of cross platform problems, so they can avoid requiring their users to futz around.
> Someone doesn’t have to have anything against other browsers to prefer using their favorite browser without futzing around with browser-site combinations.
Yes, this is irritating. If I encounter a site/app with browser requirements, I’m going to find an alternative to that site/app, not use a different browser.
Here are some Safari-specific issues I have met when developing a website in the past two years:
* font being displayed way bigger than in the other browsers - had to add normalization rules specific of Safari
* Parsing dates in the format "YYYY-MM-DD HH:MI:SS" not working, had to convert to ISO-8601 using a regex (the dates in original format were received from a third-party website).
* Interactions in maps not working using leaflet library (version 1.7 at the time). Fixed by switching to maplibre, which turned out to be a great move for other reasons.
* HTML in SVGs (via ForeignObject) are always displayed on top of the SVG content, making it impossible to annotate HTML with SVG markup (arrows, circling stuff).
Plus some issues with `backdrop-filter:blur`, although this CSS is also problematic elsewhere.
All in all, it felt like having to deal with Internet Explorer 10+ years ago: the other browsers work well out of the box, and tricks and workarounds need to be identified for the bad browser.
Finding maplibre 'better' was more valid at the time than today, and is also subjective. The creators and maintainers of both libraries have done some great work (and are still doing so).
Back in January 2022, the stable version of leaflet, v1.7.1, was from September 2020, and was affected by some small bugs degrading the user experience. Although the release of following version seemed close, there was no clear schedule for it, and I had concerns about how maintained the library would remain.
As of today, the bug from 2015 where there is some white space between map tiles on fractional zoom levels [0] is still open.
Also, leaflet was a pain to integrate in Svelte Kit framework, because it depended on `window` and-or `document`, not available at server side.
Maplibre, on the other hands, with a feature set roughly equivalent to Leaflet, benefited from much more frequent releases, and seemed more stable across browsers and devices. It was also easier to make it work in Svelte kit.
It’s not. We’re now in the same situation we were in 20 years ago with Internet Explorer, where other browsers are measured by “does it act like Chrome?”
Yes, it does have bugs and shortcomings – but all browsers do. When a predominantly Chrome developer finds something that doesn’t work in Chrome, the perception is that the functionality is not ready for primetime; when they find something that doesn’t work in Safari, the perception is that Safari is bad; when they find something that doesn’t work in Firefox… ha, just kidding, they don’t test in Firefox. Firefox is the new Opera.
Try making a game for Safari and then tell me it's not hard. It's definitely not just a case of different browser quirks. Safari is so far behind Chrome and Firefox that it's not worth supporting.
Apple genuinely have some of the weirdest “fans” I’ve ever seen.
To sit there and try to tell an audience of largely web developers that Safari’s reputation as the new IE is totally unfounded as though they don’t know for themselves exactly what the last ten years were like themselves.
Or as though multiple governments across the globe didn’t just spend the past couple of years opening multiple antitrust investigations looking at what a problem Safari had become.
No… apparently the problem is just you and your perceptions and whatever other weird gaslighting that seems to come with these defences.
It's not just Safari, it's every webkit implementation, e.g. Orion, etc.
I too prefer the webkit rendering and use that daily.
People blaming Webkit for being behind should realise the amount of people working on Webkit vs. Blink and question whether they want another internet explorer.
Is Safari really that hard to develop for? Name one feature this site needs that won't run in safari. WebKit has been getting a lot better recently, I feel like not supporting Safari at this point is because of one of three things: you're too lazy to try it, don't have a Mac, or you are stuck to the opinion that Safari is somehow behind Chrome or Firefox in major ways.
I use safari daily and *never* have a problem with a site not working. Ever. So I doubt there's some new web api that this site needs that doesn't work on Safari.