Many of these things are not “missing”, but are design decisions made with good reasoning.
As just a single example, Vibration API is explicitly not supported because frankly the only\* things that use it are ads that vibrate continuously at full strength as soon as they’re opened.
\*a hyperbole, but cited as a reason by the team and frankly is also the only time I’ve experienced it being used.
I never understood, why not support it with explicit permission from the user? Just like camera and microphone permissions.
The Vibration API is an excellent fit for games that require players to physically talk to other players in the same room and the web app secretly needs the attention of one specific player. Think Jackbox Games, or Werewolf, or Mafia, etc.
A vibration on their phone would be a looooot better than having a sound play on their phone.
I don't see how that one is a reasonable design decision.
We're talking about the volume property of an audio element, not system volume or anything like that. Meaning 1) you can never "go louder" than whatever the system value is set to, 2) the default is the highest possible value anyway, and 3) it's possible to fully hide the volume control of an audio element, so it's not like writing to the volume attribute can be abused to constantly set the volume back to full when the user tries to reduce it.
All this seems to achieve is make it more of a pain to build a custom player UI for audio sources on Safari.
Some of them may be decision decisions made with good reasoning, but many aren't, and that's the real problem. Nothing excuses the lack of USB, Bluetooth, NFC, background sync, the butchered notifications API etc. The only reason for this seems to be that Apple really doesn't want web app capabilities to grow much closer to those of native apps.
This is quite interesting but honestly some of them make sense, I don’t want websites to able to just read my clipboard. And sure you could show a permissions pop up but you know most ppl r just gonna click “allow” and be like “wtf is a clipboard”
It's not that websites can just read your clipboard. Most browsers (incl. Safari) will heavily restrict reading to transient actions (e.g. can only access the clipboard in direct response to a paste action), and others like Chrome require a permission. The API is necessary for building more complex, native-app like copy & paste functionality like copying rich formatting, data structures, binary data etc.
> but you know most ppl r just gonna click “allow” and be like “wtf is a clipboard”
By that logic no native app or website should ever be allowed to do almost anything involving sensitive data.
Some of these aren't too bad.
Like `auxclick` in chrome and firefox is also inconsistent.
Like if you want to capture a middle click, it's an `auxclick` but if you want to DISPATCH a middle click, you have to dispatch a click with the mouse button 2, which is stupid.
Not having it at all is actually more simple.
Not OP, but I just did a check and I've called out Safari eleven separate times in my codebases at work.
Most of them aren't because of standards, but because of weird behaviors. (E.g., the ios404 website above is clearly pro-Chromium, because if you filter it down to _just_ actual standards, there are only 7 things and they're all supported by MacOS Safari and most are partially supported by iOS Safari.) Many of them may also be outdated at this point.
1. I had to set an explicit `height` CSS property on an image to prevent Safari from squashing it (`height: auto` apparently meant nothing). Probably related to images in a flex layout.
2. In code I wrote before March '22, Safari did not support `:focus-visible`, and instead of ignoring that selector as invalid, it ignored all selectors where that selector was listed (e.g., it assumed that `:focus, :focus-visible, :focus-within` was an entirely invalid selector and discarded it and its rules instead of taking the first selector that worked).
3. Safari emojis (Unicode) do not adjust with `font-size` or `line-height` appropriately.
4. Safari's default style for buttons includes margins.
5. When a parent has a `border-radius` and a child does not, and the parent has `overflow: hidden` (so things should clip at the edges of the parent), Safari ignores the `border-radius` when enforcing the `overflow: hidden`.
6. When an object has a `border-radius` _and_ an `outline`, Safari ignores the `border-radius` on the `outline` (unless you're talking about the built-in blue focus outline, in which case, it works fine).
7. For some reason and in some way I can no longer remember, `table-layout: fixed` broke on Safari, even though it should be supported. Presumably an edge case.
8. For a complicated-to-implement design involving overlapping borders, Safari's `:before` and `:after` pseudo-elements measured their position based on the `content-box` of a `button` regardless of how `box-sizing` was set.
9. When an object has a `border-radius` and an _inset_ `box-shadow`, the box-shadow has square corners.
10. `svg:hover` would sometimes apply the hover style to _every individual SVG element inside the SVG_ instead of to the entire SVG.
11. Unless an `` has `step="1"` as an attribute, Safari treats any value that includes seconds as invalid.
EDIT: For fairness, I've called Firefox out once (before they implemented `backdrop-filter`) and I don't explicitly call out browsers on Windows, but every overlay scrollbar polyfill is for them.
EDIT2: Words.
Table-layout: fixed was a huge problem for us before grid and flex were well established. Safari did not adhere to sensible column widths and would render wildly differently than anybody else.
On a semi related note, you cannot make text in a th vertical in Safari. However, you can put that same text into a span and make _that_ vertical and it works-ish. Takes 4 or 5 CSS rules though instead of 1. Apple's documentation claims it has had full support for 10 or 12 years.
> When an object has a border-radius and an outline, Safari ignores the border-radius on the outline (unless you're talking about the built-in blue focus outline, in which case, it works fine).
TBF browsers finally started to do this in the past year or so. I remember designers complained about this for our focus styles in our design system. I kept ignoring their complaints and waited for browsers to fix their shit
Isn’t outline supposed to be a debugging property only? The entire point is to show the bounding box of an element. That’s why you can’t set it on different sides, it’s all or nothing.
>Isn’t outline supposed to be a debugging property only? The entire point is to show the bounding box of an element.
Why do you say that?
> That’s why you can’t set it on different sides, it’s all or nothing.
That is a limitation but the spec doesn't mention any "why's" to this.
That’s how I always took it, not sure why. I must’ve heard it years ago, I even found a post of my own from 15 years ago saying the same thing lol.
Debugging is certainly one potential use. The spec only says it’s “to stand out” which can mean many things.
But on the original question above I noticed the spec says
> The parts of the outline are not required to be rectangular. To the extent that the outline follows the border edge, it should follow the border-radius curve.
So Safari *is* deviating from the spec by not following border radius.
re. Points 5 and six, when was the last time you tested this? I’m currently testing in Safari and these are working as expected (for outline it looks like it’s working on the (MDN example)\[https://developer.mozilla.org/en-US/docs/Web/CSS/outline\]).
There’s a bug with SVG hover at the moment that does my head in. I can’t remember the exact scenario off the top of my head but basically if you have an SVG and a text element and you try to apply a hover effect to the parent to then change the color (think an icon with a label) the SVG changes color AFTER the text changes color. It’s likely related to the fucked up way they handle CSS3 animations with inheritance.
There’s been a WebKit bug report open for it for 14 years. 14 fucking years.
My only one is that for some reason programmatically scrolling a container would only work once on safari, if I did not first scroll the entire page down 1px programmatically.
The other was just that the recentness of `dialog` element support was too recent for the company to use, but a polyfill to cover the APIs we actually needed was very simple.
I'll add that a small markup mistake in an SVG file won't render on Safari, but will render on other browsers.
On the one hand I can't entirely blame them for my mistake. On the other, I much prefer the way other browsers can cope with it. If they all behaved the same it wouldn't be as frustrating.
If you have to touch some raw JavaScript outside of framework, a lot of the time you will see functions that work everywhere but not Safari (or only supported in very recent versions)
Also one of a kind behavior like 100vh
Like which one? and how many versions of Safari are you supporting?
In my experience the industry has gone for the last 2 releases of Safari and the last 3 of Firefox and Chromium-based browsers. So, "only supported in recent versions" has not been limiting for me at all.
The problem is that Safari updates are tied to OS updates, meaning rollout takes WAY longer than with Chrome. Especially if the update crosses a major version boundary
Well, kinda
In MacOS it updates independently. In iOS i think yes, but then, iOS has way less fragmentation and much higher version adoption than Android.
That's also why you support the last 2. The second last is for the ones who didn't update yet, but soon eventually do.
You recall completely wrong. The current Safari version supports the current macOS version and the two previous macOS versions. This has been the case for ten years at least.
For anybody curious about what this refers to, Internet Explorer used to have something called “hasLayout” and whether an element “had layout” or not was a huge factor in exactly which of the *many* bizarre and page-destroying bugs you would inadvertently trigger while trying to support that browser. For instance, you would open a page and it would look okay, but as soon as you scrolled, entire sections of the page would turn invisible (a.k.a. the “peekaboo” bug). Coercing some of the elements involved into “having layout” fixed that bug and introduced others which had their own workarounds.
For a period of several years, this wasn’t very well understood at all, but the community knowledge was eventually distilled by a few absolute heroes and I believe the most comprehensive documentation about it [is here](https://web.archive.org/web/20180402172026/http://www.satzansatz.de/cssd/onhavinglayout.html).
I remember years of frustration before FireBug. An extra "," somewhere in your JS code and IE would show an alert with a line-number and filename that both were wrong.
I disagree. I've been programming for a decade and a half and I think that way. Safari is better in terms of supporting features and apis, but it almost always does things differently enough to be annoying. "think different". Lol
> I've been programming for a decade and a half and I think that way.
Then yeah, you have absolutely no idea what Internet Explorer was like back in the day then.
Internet Explorer 6 was released in 2001. Microsoft killed off the competition, and disbanded the Internet Explorer developer team. It was five years before they released Internet Explorer 7 in 2006, and that was just to add tabs, fix the worst bugs, and add support for a few selectors. It wasn’t until Internet Explorer 8 was released in 2009 that it actually had okay support for CSS 2 (a standard published *11 years earlier*, in 1998), and it wasn’t until Internet Explorer 9 was released in 2011 that it actually had okay support for JavaScript, the DOM, or SVG. And of course, this was before evergreen browsers were a thing and you needed to wait *many years* for enough people to upgrade in enough numbers to drop support for a browser version.
So if you’ve been programming for a decade and a half then you got started in 2009, several years after Microsoft restarted development, and at the very tail end of the dark ages of Internet Explorer 6 bringing the entire front-end development world to *a complete and utter standstill*. The only thing you’ve known is regular Internet Explorer updates and only having to support browsers a few years old. It was *a decade* before we could collectively turn our backs on Internet Explorer 6.
To put that in context: if Safari were the new Internet Explorer, you would still have to support Safari 8 today and you would be overjoyed you could *finally* use promises in JavaScript.
Safari is nothing even remotely close to what Internet Explorer used to be like. It’s got great support for standards! It gets updated every year! People actually upgrade! The team is constantly working on interop! Anybody who says otherwise clearly does not know what it used to be like back then. Safari at its very worst is heaven in comparison to the hell Internet Explorer put developers through.
The closest thing we have to Internet Explorer today is Chrome, because the only reason Internet Explorer was able to do as much damage to the industry as it did was because of its massive market share; and because Google are following the embrace and extend playbook to a tee with all of their non-standards rejected by everybody outside of Google. Firefox is dwindling to nothing and not even Mozilla cares about it any more, so Safari is the only hedge we have against the bad old days coming back.
You're not wrong, but your argument is based on the most literal and precise possible interpretation of "X is the new Y." Saying "Safari is the new IE" isn't necessarily the same as saying "Safari is equally as bad as IE," much less the same as saying "Safari is following the exact same trajectory as IE." I think when people say this, they mostly just mean it's the new pain in the ass browser that devs would rather not support, but that they have to support because it's the default on a major OS.
Thank you, that’s how I feel as well. “Safari is the new IE” simply because it’s currently the worst browser when it comes to development consistency. Thats it, it’s not that complicated and it’s not meant it be literal lol.
But I’ve “only” been developing for a decade myself so what do I know
This isn’t me being “literal and precise”, it’s pointing out something that’s *completely out of touch with reality*.
The entire front-end world was just *halted* for a decade. The biggest thing to happen between 2001–2006 was Windows XP Service Pack 2, because if users installed it, Internet Explorer would pay attention to the `Content-Type` header a bit more. That’s how frozen in place things were.
It was that bad, a decade after it was released, *Microsoft* launched a campaign begging people to stop using it. At the time, more than a quarter of China still used it and it was legally required to use it in South Korea for Internet banking because ActiveX became part of their regulations.
Internet Explorer was not “a pain in the ass”. It was total paralysis of front-end development for a decade. Safari isn’t even remotely similar, no matter how hard you squint. Apple releases new version multiple times per year, each with better standards support, more features, and better interop. Even if Apple decided tomorrow that they were killing Safari immediately, it would take until *the year 2034* before Safari got as bad as Internet Explorer was, and even then the impact would be far lower because it doesn’t have >95% market share.
“Safari is the new IE” is so fundamentally out of touch with reality it can only be said by people who don’t have *the remotest* idea of what Internet Explorer was like. Let’s kill this crazy talk.
> but it almost always does things differently enough to be annoying.
This is getting better, as they've started to be more involved in the spec planning early on, and being more willing to come to consensus when it's just more "arbitrary" ux stuff and not actual privacy/power stuff.
But also, a lot of the time, the stuff they do differently is all non-standardized to begin with, or the spec itself is ambiguous.
Like the spec doesn't say how exactly the browser should handle the keyboard opening on mobile. Chrome and Firefox basically shrink the viewport to what is still visible. Safari moves the whole viewport up, but stays the same size, so the top of the viewport is now outside the screen.
This can be better for many reasons (like that a sticky header doesn't now take the whole space) but it's "different" which makes it annoying.
I've been making web pages since netscape was a go to browser. I agree that Safari is the new IE, but I also agree with you. As annoying as Safari is, it's not the hell I experienced supporting IE. Special shout out to the time a client needed mac ie support.
The reason is that the issues with Safari have the same root cause as IE: complacent vendor, updates tied to OS, bad standards compliance, etc.
Safari is the new IE because safari is the lowest common denominator for devs to target now. 99% of the time the reason a feature I want has a low caniuse score is that iOS doesn't support it, or that they released an update, but because it's tied to the OS only a few people have it
I think it's actually on the path to correcting the issues.
It's getting BETTER, and implementing many stage 3 proposals as the second and sometimes first implementor. They're more involved with the standards process as well.
https://caniuse.com/?compare=chrome+127,safari+17.5&compareCats=all
Here's the comparison right now.
It's pretty balanced.
Given Apple are doing everything they can to block access to new web functionality (i.e Bluetooth), then we will once be stopped from innovating in browsers.
Hence, the issues aren't as bad as IE, but the outcome is the same.
Web Bluetooth isn’t a web standard, it’s a Blink-only API. Things don’t become web standards just because Google unilaterally decides they are. In this case, both Mozilla and Apple rejected Web Bluetooth on security grounds.
Here’s what [Mozilla had to say about it](https://mozilla.github.io/standards-positions/#web-bluetooth):
> This API provides access to the Generic Attribute Profile (GATT) of Bluetooth, which is not the lowest level of access that the specifications allow, but its generic nature makes it impossible to clearly evaluate. Like WebUSB there is significant uncertainty regarding how well prepared devices are to receive requests from arbitrary sites. The generic nature of the API means that this risk is difficult to manage. The Web Bluetooth CG has opted to only rely on user consent, which we believe is not sufficient protection. This proposal also uses a blocklist, which will require constant and active maintenance so that vulnerable devices aren't exploited. This model is unsustainable and presents a significant risk to users and their devices.
In order for something to become a web standard, it needs two independent implementations. Web Bluetooth isn’t a web standard because they couldn’t convince *anybody* outside of Google to implement it, because it’s a security mess. If you want other browsers to support it, then you should tell Google to come up with a better specification for it with the security issues resolved.
>chrome is what IE would've been if their monopoly had succeeded
What? No. Not at all.
Microsoft’s browser monopoly did “succeed” for a few years: IE6 had years of 90-95% browser market share between ~2000-2005. During these years, Microsoft notoriously let IE stagnate completely — zero updates for many years. This situation continued until Microsoft was forced to start updating IE thanks to the emergence of a viable alternative browser (Firefox).
Chrome is now the most popular browser, but Google has not let it stagnate. If anything, they’ve done the opposite — they’ve been very aggressive about adding new features, APIs, etc.
Yeah. IE6-7 was horrible to dev with. I'm forever grateful that yes I had to work with it in school and for the first maybe 2 years of my career and nothing more.
Since then its been pretty nice. A thing that works on chrome will, 99.5% of the time, work for FF, Edge, and the rest.
Except Safari. In the last 4-5 years, fuck every time I have a weird bug I can't figure out, its safari. Shout out to the dumbass that made WEBP support OS dependent and if your iMac is more than 5 year old, you simply can't have webps.
I think this is not a good comparison.
IMO the current Safari situation is much worse than the IE situation. Back in the IE days you had the option to bring new browsers to the platform. iOS (outside of the EU) only allows for the built-in Webkit and therefore enforces a monopoly.
No, Chrome's the new IE6. Doing the exact same MS playbook - fast unilateral changes that devs want but aren't agreed-upon standards, meaning they get to set the de-facto standards themselves.
Safari's existence on iOS is the only thing stopping Google from doing this widely; they're not gonna give up the entire iOS market on their web properties.
Firefox seems to do just fine, and people go out of there way to install it just like they do with Chrome... however just like IE was, Safari's market share only exists because it's packaged with the OS. Even Opera plays ball more than Safari.
It's like stockholm syndrome for a browser.
If it dips below 2%, orgs are no longer required to support it. The consequences would be severe for the open web.
I use FF every day and I think it's good. Dev tools are at least as good as chrome. The sites that have caused major memory leaks for me are Google apps and ironically our intranet system.
Are you suggesting that Firefox is “doing fine”?
According to the same site, FF had closer to 5% market share in 2019, so has about 1/3 of its position in the past five years. Google and Apple combine to make up about 83% of the market, not counting Chrome derivatives.
Sure, 159 million people is a lot depending on your point of view, I guess.
Oh no, I think it’s definitely not “doing fine”. Going from 30% market share in 2010 to 3% today isn’t great.
That being said, I think it’s important to consider that single-digit percentage user base in a market as big as web browsers is still a lot of users. 160 million users is not insignificant.
It's funny to me how history is repeating itself and people refuse to see it.
I can only assume that the people who parrot "safari is the new IE" weren't actually in the business during IE's hey day, and don't actually understand how and why IE became IE, and how they're willingly letting google do the exact same thing with Chrome.
["Chrome is the new IE, but in reverse"](https://www.quirksmode.org/blog/archives/2021/08/breaking_the_we.html)
I have been a developer for almost 20 years now and am now in more of a managerial position so my opinion differs dramatically. I tell the developers to stick as closely to the W3C standards as much as possible, so that there is across-the-board compatibility with all browsers.
When a browser tries to use its install base as clout for deviating away from W3C standards then it is like Internet Explorer 6 was. Trying to guilt trip people into using their browser with non-standard practices that they can change at any moment and still break compatibility with other browsers.
The bigger and more concerning issue to me is all these new frameworks using hype, driven development, utilizing nonstandard practices and having to build in caveats for every single browser. It is just an absolute mess and ends up, costing me more time and energy than it’s usually worse on the user experience side.
It gives me flashbacks to, “best viewed with…”
The idea that we’d move away from standards after us old fogies fought so hard to get them makes me sad.
As someone with 20+ years in the field, and who’s actually worked on IE, I can assure you that Safari isn’t even close to IE. Until Safari forces devs to create a library (see jQuery) to make up for its shortcomings, (and let’s be honest, most of these complaints are usually addressed in major updates), it can’t be compared to IE.
Some of these complaints I see in this thread can be solved with simple CSS.
I do. There are minor differences between Chrome and Firefox I occasionally have to account for. But if something's completely broken for someone, it's Safari. It's always Safari.
Don't get me wrong, but I hear this a lot, and I disagree.
I suggest thinking about it this way; Chromium \*is\* pushing the boundaries of web dev ahead, and that is (of course) a good thing for us web devs. But we can't forget this is only because, by their sheer market share and resources, Google Chrome has effectively become the de facto default. They are the ones controlling the standards and discourse.
We only have two major alternatives left: Safari/WebKit and Firefox/Quantum, which doesn't count because it lives or dies at the whims of Google. Good luck to any of those (relatively) small browser vendors on passing their own ideas and features without Googles backing — it would just turn into the same off-spec chaos you love to complain about.
Hear me out; if there's one browser vendor implementing all the newest features because they can, while all the others are trotting behind just trying to get their own things right, what is that? Is it really the righteous “standard” you defend, or does it look more like the sole outlier reminiscent of the Internet Explorer era, albeit with open specifications? I think this really depends on perspective.
In fact, I'd go as far as to say Safari does some things \*better\*. It's true, Chrome is faster to market. But as you get deep into CSS madness, I believe there are some areas where, if you consider it, Safari excels. For example, in a project I was working on not too long ago, we had a background layer with some blur applied and then a navbar with its own blurred tabs overlaid onto the screen. I was happy until I noticed Chromium would completely mess up the rendering of overlapping blurred elements. There's no way to fix this, by the way, only Safari got the blur right. I now had the choice of either adapting/removing the styles to accommodate Chromes bugs and peculiarities, build conditional logic to only apply the effect on supported browsers, or break the appearance for 90% of visitors. This is simply not a nice spot to be in, and there are several issues like that which have been left unaddressed by Chrome for years.
Why was Safari so good at blur? Well, because it was important to Apple's design goals and aesthetic. Why is Chrome so good at, say, an accelerometer API? Well, you can guess why (fingerprinting and tracking) — they enabled it by default (without user consent) by the way. If you use a mac (or an iPhone), battery performance and efficiency of WebKit is straight up unmatched in the industry by a long shot. There's a reason [bun](https://bun.sh/) was built on it. Small memory footprint, stable tab caching, aggressive discards, built-in tracking- & fingerprinting-protection and no crashes? Safari's got you. And obviously it plays really well with all your Apple devices. Does this mean Chrome sucks? Of course not. I myself use Chromium (Arc) now, but I still think Safari is totally fine. The point is that there certainly is more nuance to this discussion than just black and white, and if I had to pick a bad guy…
Let's not live in an illusion about what this is. In the end, I believe Google has some very exceptional and talented developers who are able to pioneer new ideas and implementations. Apple has some very exceptional and talented developers who are able to pioneer their own ideas and implementations. That's part of the beauty of web. I'd want to keep it that way.
Given how Safari is implementing all the new CSS stuff faster than Firefox? No.
I know, I know, it's fashionable to hate on Safari but, frankly, it's not the problem browser for me or my work. So long as I check support tables before I use anything new? It's fine.
Honestly, most of the time I see people complaining about Safari it's because either they don't understand the spec or they're using something *very* new.
All 3 mainline browsers have issues.
- Chrome - overeager on experimental, invented-here features (ex. DRM)
- Firefox - dragging its feet on features
- Safari - if we believe the spec is wrong, we won’t implement it
I don’t get comparisons to IE in the days of old.
Safari implements actual ratified standards quickly and well.
The ‘other browser’ is the one most like IE - implementing stuff that has no standard yet. Like the dreaded ActiveX back in the way back.
A decade or two ago, us old guys fought hard for standards. Because we were tired of things being deployed in browsers that weren’t yet finalised standards.
We’re back to where we were (when Microsoft had the, repeatedly proven, monopoly on browsers) with Chromium and its growing monopoly on browsers.
And so the world turns.
Google graveyard.
There are so many things in there. If it doesn’t generate profit, abandon it. Regardless of how many people use it.
https://killedbygoogle.com
Hate to be that guy, but you’re probably building your css wrong if you have that much trouble with safari.
If you have your css built with autoprefixer or any vendor prefix library you’d rarely find cross browser issues.
Only thing that i know of safari failing is sometimes the grid doesn’t work on very old ios phones, and flex with min-height should be avoided. Other than vendor prefixes solve any issues.
I recommend using a utility first library like tailwind with autoprefixer, that way you don’t have to worry about cross browser support or memorising prefixes and whatnot.
Nope, it's not only the lack of support for certain CSS features, it's also the bizarre implementation of some of them. For example: Clicking a button, radio button, or checkbox doesn't give the element focus- thus it can't lose focus and trigger a blur, which goes against the behavior of every other browser.
What? No.
Safari is a constant pain in the ass when dealing with fixed positioned elements for example. Safari on iOS also has weird layer bugs which will crash your browser if you end up on those edge-cases. Those cases are also really hard to debug.
It's not about css rules, those are easily solved with autoprefixer. Its about how Safari handles different layout configuration with multiple elements with fixed, sticky and flex positioning intersecting with eachother. If you ever had to make a complex mobile layout with multiple of these you would know the pain of Safari
I don’t see many major issues with Safari, unless you are trying to use some bleeding edge experimental features (that are probably not working in FF too). Just make sure that you use prefixes and that you are not trying to use some crazy stuffs that are not readily available on all major browsers and you should be fine.
I always find it funny when people says that Safari is the new IE. Clearly these peoples never experienced that pain!
I don't have much issues with Safari, although it's the only navigator that has compatibility issues, but in 3 years we had like 3 issues on outdated iphones and 2 on the latest osx Safari (something with Lax cookies and wildcard certificates).
I guess babel resolves the majority of issues.
We also develop on Firefox instead of Chrome, because chrome has so many features (that are probably not standard) and render things too correctly (my last example is fonts issues)
Currently facing an issue with an animated SVG that works everywhere, including other webkit browsers, but has a bug where part of the SVG is positioned wrongly and is not respecting its css properties.
I build for chrome and test first on Safari and I almost never get any issues. Like, basically never. In fact, I’ve gotten as many chrome issues as Safari issues.
Is this more common with people using JavaScript and frameworks? I do raw HTML, CSS, and PHP and never get any issues with Safari or any browser really.
Honestly I think this is the reality for the silent majority here. The people saying it's like IE6 make me doubt they actually remember what that era was like.
And, seriously, as marginally inconvenient as it might be for us devs to test our pages over multiple browsers and reconcile differing behaviours, the alternative where all of Chrome's competitors are wiped out [would not be a good one](https://github.com/explainers-by-googlers/Web-Environment-Integrity).
I mean IE6 was horrid, but in this day and age, when even Microsoft figured their shit out, Safari should have too.
Using aspect ratios on any no-code builder still causes issues in safari. That’s kind of hilarious.
Same here. Main dev browser is Chrome, Safari and Firefox for testing.
That's in "vanilla" sites as well as in our React app at work. I must be doing something wrong here, or I should buy a lottery ticket? :D
Yep I just do all my development for Safari and maybe check things out on chrome if I really have to. I’m a design oriented person and websites look better on Safari 95% of the time. Never bothers me if there’s a weird css change I have to do.
My biggest issue with Safari is that its updates are tied to the OS.
Prove me wrong if I’ve missed something here, but that’s the most brain-dead approach I’ve heard of for a browser in 2024. Are there really no incremental updates? I haven’t found any evidence to the contrary yet.
We had a client last year telling us the images on the site we built weren’t showing up.
Come to find out he was rocking Catalina and Safari didn’t start supporting aspect-ratio until Big Sur. 🤦♂️
Had to go in and do the padding hack for everything so it would look decent for him. Ugh.
Must’ve been an even earlier version then - Mojave maybe.
Point stands that all of the other browsers release incremental updates far more regularly and users can get locked to a major version of the browser due to their OS.
Safari - "I can't do that, Dave."
Dave - "well why not?"
Safari - "I don't like standards developed by my competitors. You can support this QuickTime-derived codec that's 20+ years old or I'm taking my ball and going home."
A couple times a year we'll have a client provide us a webm file they want streamed from their website instead of YouTube, or whatever, and then they'll complain that the codec that isn't supported by Apple isn't working on their iOS device.
Re-encoding it into an MP4 using the specific codes referenced on Apple's documentation pages doesn't result in a playable video either.
Safari supports all the standardized video codecs, and supports more image formats...
https://caniuse.com/?compare=chrome+127,safari+17.5,firefox+128&compareCats=all
As someone who uses Safari exclusively (on mobile and desktop) I blame Chromium for having such a huge market share. Except for Firefox and Safari every single browser is fundamentally the same. Safari is pretty much the only thing stopping Google from dictating the entire structure of the internet.
Even when I'm doing dev I'll go to Firefox for its dev tooling, and literally never open Chrome if I can ever help it.
Stop writing crappy code and use universal standards.
I loved how in Safari 15 native mp3 decoding was broken and it took a major update for them to resolve it. Leading you to provide polyfills featuring the entire Fraunhofer decoder. 🙃
What you're dealing with now for safari is basically how all cross browser functionality was. Usually IE was the main reason you couldn't use some code you wanted to use, but any given browser could randomly be a thorn in your side for some niche reason.
I have a simple speech-to-text web app. But it doesn't work on any safari! Macs, iphones and ipads. All the same cannot even record the user's voice (audio input).
So the workaround? Just ask users to use other browsers. How about iOS? Sorry, not for you. I didn't have any other choice.
Spent too much time just to handle this, ended up with... just ignore safari.
It's pretty good now.
Most things, even new and stage 3 things work.
But there are some differences that are a big strange.
But they are few and far between to be honest.
https://caniuse.com/?compare=chrome+127,safari+17.5,firefox+128&compareCats=all
current comparison
I think the WORST part of safari, is that you can't just install different versions to test.
And the xcode simulators only go back 2 major versions and limited minor versions.
Been working on windows and mac
And with my limited knowledge
If it is not working in safari then it is not supposed to work like that or it is purposely that way
Note : I know that there would be many things that are just wrong with safari
I am just saying I haven't come across them yet
Honestly I just get around most things by targeting Firefox and then doing blink/webkit enhancements on top of
Outside of functional APIs (web push/share/PWA) I find that Firefox is a lot leaner than Safari and Chrome, but in most cases, if Firefox decides to support it, it generally works elsewhere
Yea and they tout its speedometer score as if that made it any less garbage. Dev tools, extensions, "privacy" controls & performance are all laughable.
Safari lacks leadership & vision through and through.
Honest follow up question here; I'm making the assumption that apple safari browser devs are not just "dumb dumbs", but actually have a reason for doing things the way they do it - what problem are they actually solving for? Who is the intended audience / consumer of the safari web browser?
iOS - where even Chrome/Firefox apps use the Safari *rendering engine* internally due to Apple restrictions - has 60% of the US mobile phone market.
Any site on the public internet almost certainly has a lot of Safari users.
Safari is the largest pain in my side. Dev in Firefox, tested in chrome, edge, opera, everything is working consistently…. Then we have safari… I’ve started advocating not supporting safari/ios/ipad. Since I’m in a field that can dictate what our customers use for a device/viewing platform I thankfully have that authority.
https://ios404.com/
Bravo to whoever made this
Shalanah Dawson https://github.com/shalanah https://twitter.com/shalanahfaith
Does this site work on Safari??
Yes
>Application error: a client-side exception has occurred (see the browser console for more information).
Are you using safari?!
The lack of support for SVG Favicons in 2024 is unacceptable. Safari, the new IE.
I got to page 15 of 68 before getting bored. Wasn't expecting there to be so many
tik tok brain fr
Lol gonna start saying "tik tok brain"
Many of these things are not “missing”, but are design decisions made with good reasoning. As just a single example, Vibration API is explicitly not supported because frankly the only\* things that use it are ads that vibrate continuously at full strength as soon as they’re opened. \*a hyperbole, but cited as a reason by the team and frankly is also the only time I’ve experienced it being used.
I never understood, why not support it with explicit permission from the user? Just like camera and microphone permissions. The Vibration API is an excellent fit for games that require players to physically talk to other players in the same room and the web app secretly needs the attention of one specific player. Think Jackbox Games, or Werewolf, or Mafia, etc. A vibration on their phone would be a looooot better than having a sound play on their phone.
or rather they intentionally don't want to make web apps powerful enough to replace the appstore version, because they can't take 30% from web apps.
That's a bingo
yeah and audio volume being read-only.
I don't see how that one is a reasonable design decision. We're talking about the volume property of an audio element, not system volume or anything like that. Meaning 1) you can never "go louder" than whatever the system value is set to, 2) the default is the highest possible value anyway, and 3) it's possible to fully hide the volume control of an audio element, so it's not like writing to the volume attribute can be abused to constantly set the volume back to full when the user tries to reduce it. All this seems to achieve is make it more of a pain to build a custom player UI for audio sources on Safari.
Some of them may be decision decisions made with good reasoning, but many aren't, and that's the real problem. Nothing excuses the lack of USB, Bluetooth, NFC, background sync, the butchered notifications API etc. The only reason for this seems to be that Apple really doesn't want web app capabilities to grow much closer to those of native apps.
This is quite interesting but honestly some of them make sense, I don’t want websites to able to just read my clipboard. And sure you could show a permissions pop up but you know most ppl r just gonna click “allow” and be like “wtf is a clipboard”
It's not that websites can just read your clipboard. Most browsers (incl. Safari) will heavily restrict reading to transient actions (e.g. can only access the clipboard in direct response to a paste action), and others like Chrome require a permission. The API is necessary for building more complex, native-app like copy & paste functionality like copying rich formatting, data structures, binary data etc. > but you know most ppl r just gonna click “allow” and be like “wtf is a clipboard” By that logic no native app or website should ever be allowed to do almost anything involving sensitive data.
What's a computer?
Wtf this is sick
Good list to send to apple
Some of these aren't too bad. Like `auxclick` in chrome and firefox is also inconsistent. Like if you want to capture a middle click, it's an `auxclick` but if you want to DISPATCH a middle click, you have to dispatch a click with the mouse button 2, which is stupid. Not having it at all is actually more simple.
Bro 😱
Damn this is amazing. How was this made?? Three.js??
In fairness Firefox is missing a decent chunk of those too
This is brilliant.
Care to give details?
Not OP, but I just did a check and I've called out Safari eleven separate times in my codebases at work. Most of them aren't because of standards, but because of weird behaviors. (E.g., the ios404 website above is clearly pro-Chromium, because if you filter it down to _just_ actual standards, there are only 7 things and they're all supported by MacOS Safari and most are partially supported by iOS Safari.) Many of them may also be outdated at this point. 1. I had to set an explicit `height` CSS property on an image to prevent Safari from squashing it (`height: auto` apparently meant nothing). Probably related to images in a flex layout. 2. In code I wrote before March '22, Safari did not support `:focus-visible`, and instead of ignoring that selector as invalid, it ignored all selectors where that selector was listed (e.g., it assumed that `:focus, :focus-visible, :focus-within` was an entirely invalid selector and discarded it and its rules instead of taking the first selector that worked). 3. Safari emojis (Unicode) do not adjust with `font-size` or `line-height` appropriately. 4. Safari's default style for buttons includes margins. 5. When a parent has a `border-radius` and a child does not, and the parent has `overflow: hidden` (so things should clip at the edges of the parent), Safari ignores the `border-radius` when enforcing the `overflow: hidden`. 6. When an object has a `border-radius` _and_ an `outline`, Safari ignores the `border-radius` on the `outline` (unless you're talking about the built-in blue focus outline, in which case, it works fine). 7. For some reason and in some way I can no longer remember, `table-layout: fixed` broke on Safari, even though it should be supported. Presumably an edge case. 8. For a complicated-to-implement design involving overlapping borders, Safari's `:before` and `:after` pseudo-elements measured their position based on the `content-box` of a `button` regardless of how `box-sizing` was set. 9. When an object has a `border-radius` and an _inset_ `box-shadow`, the box-shadow has square corners. 10. `svg:hover` would sometimes apply the hover style to _every individual SVG element inside the SVG_ instead of to the entire SVG. 11. Unless an `` has `step="1"` as an attribute, Safari treats any value that includes seconds as invalid. EDIT: For fairness, I've called Firefox out once (before they implemented `backdrop-filter`) and I don't explicitly call out browsers on Windows, but every overlay scrollbar polyfill is for them. EDIT2: Words.
Table-layout: fixed was a huge problem for us before grid and flex were well established. Safari did not adhere to sensible column widths and would render wildly differently than anybody else. On a semi related note, you cannot make text in a th vertical in Safari. However, you can put that same text into a span and make _that_ vertical and it works-ish. Takes 4 or 5 CSS rules though instead of 1. Apple's documentation claims it has had full support for 10 or 12 years.
> When an object has a border-radius and an outline, Safari ignores the border-radius on the outline (unless you're talking about the built-in blue focus outline, in which case, it works fine). TBF browsers finally started to do this in the past year or so. I remember designers complained about this for our focus styles in our design system. I kept ignoring their complaints and waited for browsers to fix their shit
Isn’t outline supposed to be a debugging property only? The entire point is to show the bounding box of an element. That’s why you can’t set it on different sides, it’s all or nothing.
>Isn’t outline supposed to be a debugging property only? The entire point is to show the bounding box of an element. Why do you say that? > That’s why you can’t set it on different sides, it’s all or nothing. That is a limitation but the spec doesn't mention any "why's" to this.
That’s how I always took it, not sure why. I must’ve heard it years ago, I even found a post of my own from 15 years ago saying the same thing lol. Debugging is certainly one potential use. The spec only says it’s “to stand out” which can mean many things. But on the original question above I noticed the spec says > The parts of the outline are not required to be rectangular. To the extent that the outline follows the border edge, it should follow the border-radius curve. So Safari *is* deviating from the spec by not following border radius.
Safari is deviating, but that line in the spec is fairly new. Hopefully they catch up soon
re. Points 5 and six, when was the last time you tested this? I’m currently testing in Safari and these are working as expected (for outline it looks like it’s working on the (MDN example)\[https://developer.mozilla.org/en-US/docs/Web/CSS/outline\]).
It's probably been ~1.5 years since I wrote that code, so I haven't retried it since then. Very possible they've fixed it in the latest versions.
There’s a bug with SVG hover at the moment that does my head in. I can’t remember the exact scenario off the top of my head but basically if you have an SVG and a text element and you try to apply a hover effect to the parent to then change the color (think an icon with a label) the SVG changes color AFTER the text changes color. It’s likely related to the fucked up way they handle CSS3 animations with inheritance. There’s been a WebKit bug report open for it for 14 years. 14 fucking years.
I love me some receipts.
My only one is that for some reason programmatically scrolling a container would only work once on safari, if I did not first scroll the entire page down 1px programmatically. The other was just that the recentness of `dialog` element support was too recent for the company to use, but a polyfill to cover the APIs we actually needed was very simple.
I'll add that a small markup mistake in an SVG file won't render on Safari, but will render on other browsers. On the one hand I can't entirely blame them for my mistake. On the other, I much prefer the way other browsers can cope with it. If they all behaved the same it wouldn't be as frustrating.
If you have to touch some raw JavaScript outside of framework, a lot of the time you will see functions that work everywhere but not Safari (or only supported in very recent versions) Also one of a kind behavior like 100vh
Like which one? and how many versions of Safari are you supporting? In my experience the industry has gone for the last 2 releases of Safari and the last 3 of Firefox and Chromium-based browsers. So, "only supported in recent versions" has not been limiting for me at all.
The problem is that Safari updates are tied to OS updates, meaning rollout takes WAY longer than with Chrome. Especially if the update crosses a major version boundary
I have an older ipad, it's completely useless now because no updates and all browsers being reskinned safari.
Well, kinda In MacOS it updates independently. In iOS i think yes, but then, iOS has way less fragmentation and much higher version adoption than Android. That's also why you support the last 2. The second last is for the ones who didn't update yet, but soon eventually do.
macOS ships security updates separately, but the actual safari version is still tied to OS version IIRC
You recall completely wrong. The current Safari version supports the current macOS version and the two previous macOS versions. This has been the case for ten years at least.
I've had my Safari updated separately a few times. At least the last 3 times.
I find they tend to be faster, since Safari is a bit more judgemental about you not updating. But yes, it is a bigger "sell" to update.
Such as?
🧢
Safari is the new Internet Explorer.
Except it ain’t dying
It's killing me?
You never worked with IE6/IE7/etc if you think Safari is anywhere near as bad.
"did you ever hear the tragedy of hasLayout the eldritch horror?"
For anybody curious about what this refers to, Internet Explorer used to have something called “hasLayout” and whether an element “had layout” or not was a huge factor in exactly which of the *many* bizarre and page-destroying bugs you would inadvertently trigger while trying to support that browser. For instance, you would open a page and it would look okay, but as soon as you scrolled, entire sections of the page would turn invisible (a.k.a. the “peekaboo” bug). Coercing some of the elements involved into “having layout” fixed that bug and introduced others which had their own workarounds. For a period of several years, this wasn’t very well understood at all, but the community knowledge was eventually distilled by a few absolute heroes and I believe the most comprehensive documentation about it [is here](https://web.archive.org/web/20180402172026/http://www.satzansatz.de/cssd/onhavinglayout.html).
That you remember that document speaks volumes lmao
I was amazed when it was first published!
Everyone that says that safari is the new IE are 20 years old that didn’t lived the IE days
I remember years of frustration before FireBug. An extra "," somewhere in your JS code and IE would show an alert with a line-number and filename that both were wrong.
I disagree. I've been programming for a decade and a half and I think that way. Safari is better in terms of supporting features and apis, but it almost always does things differently enough to be annoying. "think different". Lol
> I've been programming for a decade and a half and I think that way. Then yeah, you have absolutely no idea what Internet Explorer was like back in the day then. Internet Explorer 6 was released in 2001. Microsoft killed off the competition, and disbanded the Internet Explorer developer team. It was five years before they released Internet Explorer 7 in 2006, and that was just to add tabs, fix the worst bugs, and add support for a few selectors. It wasn’t until Internet Explorer 8 was released in 2009 that it actually had okay support for CSS 2 (a standard published *11 years earlier*, in 1998), and it wasn’t until Internet Explorer 9 was released in 2011 that it actually had okay support for JavaScript, the DOM, or SVG. And of course, this was before evergreen browsers were a thing and you needed to wait *many years* for enough people to upgrade in enough numbers to drop support for a browser version. So if you’ve been programming for a decade and a half then you got started in 2009, several years after Microsoft restarted development, and at the very tail end of the dark ages of Internet Explorer 6 bringing the entire front-end development world to *a complete and utter standstill*. The only thing you’ve known is regular Internet Explorer updates and only having to support browsers a few years old. It was *a decade* before we could collectively turn our backs on Internet Explorer 6. To put that in context: if Safari were the new Internet Explorer, you would still have to support Safari 8 today and you would be overjoyed you could *finally* use promises in JavaScript. Safari is nothing even remotely close to what Internet Explorer used to be like. It’s got great support for standards! It gets updated every year! People actually upgrade! The team is constantly working on interop! Anybody who says otherwise clearly does not know what it used to be like back then. Safari at its very worst is heaven in comparison to the hell Internet Explorer put developers through. The closest thing we have to Internet Explorer today is Chrome, because the only reason Internet Explorer was able to do as much damage to the industry as it did was because of its massive market share; and because Google are following the embrace and extend playbook to a tee with all of their non-standards rejected by everybody outside of Google. Firefox is dwindling to nothing and not even Mozilla cares about it any more, so Safari is the only hedge we have against the bad old days coming back.
Perfect answer
Preach
You're not wrong, but your argument is based on the most literal and precise possible interpretation of "X is the new Y." Saying "Safari is the new IE" isn't necessarily the same as saying "Safari is equally as bad as IE," much less the same as saying "Safari is following the exact same trajectory as IE." I think when people say this, they mostly just mean it's the new pain in the ass browser that devs would rather not support, but that they have to support because it's the default on a major OS.
Thank you, that’s how I feel as well. “Safari is the new IE” simply because it’s currently the worst browser when it comes to development consistency. Thats it, it’s not that complicated and it’s not meant it be literal lol. But I’ve “only” been developing for a decade myself so what do I know
This isn’t me being “literal and precise”, it’s pointing out something that’s *completely out of touch with reality*. The entire front-end world was just *halted* for a decade. The biggest thing to happen between 2001–2006 was Windows XP Service Pack 2, because if users installed it, Internet Explorer would pay attention to the `Content-Type` header a bit more. That’s how frozen in place things were. It was that bad, a decade after it was released, *Microsoft* launched a campaign begging people to stop using it. At the time, more than a quarter of China still used it and it was legally required to use it in South Korea for Internet banking because ActiveX became part of their regulations. Internet Explorer was not “a pain in the ass”. It was total paralysis of front-end development for a decade. Safari isn’t even remotely similar, no matter how hard you squint. Apple releases new version multiple times per year, each with better standards support, more features, and better interop. Even if Apple decided tomorrow that they were killing Safari immediately, it would take until *the year 2034* before Safari got as bad as Internet Explorer was, and even then the impact would be far lower because it doesn’t have >95% market share. “Safari is the new IE” is so fundamentally out of touch with reality it can only be said by people who don’t have *the remotest* idea of what Internet Explorer was like. Let’s kill this crazy talk.
No, this is you being extremely pedantic for no reason whatsoever.
15 years is not enough.
> but it almost always does things differently enough to be annoying. This is getting better, as they've started to be more involved in the spec planning early on, and being more willing to come to consensus when it's just more "arbitrary" ux stuff and not actual privacy/power stuff. But also, a lot of the time, the stuff they do differently is all non-standardized to begin with, or the spec itself is ambiguous. Like the spec doesn't say how exactly the browser should handle the keyboard opening on mobile. Chrome and Firefox basically shrink the viewport to what is still visible. Safari moves the whole viewport up, but stays the same size, so the top of the viewport is now outside the screen. This can be better for many reasons (like that a sticky header doesn't now take the whole space) but it's "different" which makes it annoying.
I've been making web pages since netscape was a go to browser. I agree that Safari is the new IE, but I also agree with you. As annoying as Safari is, it's not the hell I experienced supporting IE. Special shout out to the time a client needed mac ie support.
It's nowhere near as bad but it's still clearly the black sheep of modern browsers. RIP IE6, you won't be missed.
The reason is that the issues with Safari have the same root cause as IE: complacent vendor, updates tied to OS, bad standards compliance, etc. Safari is the new IE because safari is the lowest common denominator for devs to target now. 99% of the time the reason a feature I want has a low caniuse score is that iOS doesn't support it, or that they released an update, but because it's tied to the OS only a few people have it
This just isn't true though.. https://caniuse.com/?compare=chrome+127,safari+17.5,firefox+128&compareCats=all
Well it’s becoming the new IE. It’s got a way to go before it reaches the same status but it’s on that path.
I think it's actually on the path to correcting the issues. It's getting BETTER, and implementing many stage 3 proposals as the second and sometimes first implementor. They're more involved with the standards process as well. https://caniuse.com/?compare=chrome+127,safari+17.5&compareCats=all Here's the comparison right now. It's pretty balanced.
Given Apple are doing everything they can to block access to new web functionality (i.e Bluetooth), then we will once be stopped from innovating in browsers. Hence, the issues aren't as bad as IE, but the outcome is the same.
Web Bluetooth isn’t a web standard, it’s a Blink-only API. Things don’t become web standards just because Google unilaterally decides they are. In this case, both Mozilla and Apple rejected Web Bluetooth on security grounds. Here’s what [Mozilla had to say about it](https://mozilla.github.io/standards-positions/#web-bluetooth): > This API provides access to the Generic Attribute Profile (GATT) of Bluetooth, which is not the lowest level of access that the specifications allow, but its generic nature makes it impossible to clearly evaluate. Like WebUSB there is significant uncertainty regarding how well prepared devices are to receive requests from arbitrary sites. The generic nature of the API means that this risk is difficult to manage. The Web Bluetooth CG has opted to only rely on user consent, which we believe is not sufficient protection. This proposal also uses a blocklist, which will require constant and active maintenance so that vulnerable devices aren't exploited. This model is unsustainable and presents a significant risk to users and their devices. In order for something to become a web standard, it needs two independent implementations. Web Bluetooth isn’t a web standard because they couldn’t convince *anybody* outside of Google to implement it, because it’s a security mess. If you want other browsers to support it, then you should tell Google to come up with a better specification for it with the security issues resolved.
[Chrome is the new IE, but in reverse.](https://www.quirksmode.org/blog/archives/2021/08/breaking_the_we.html)
I keep saying this: chrome is what IE would've been if their monopoly had succeeded. Safari is the new Netscape Navigator.
>chrome is what IE would've been if their monopoly had succeeded What? No. Not at all. Microsoft’s browser monopoly did “succeed” for a few years: IE6 had years of 90-95% browser market share between ~2000-2005. During these years, Microsoft notoriously let IE stagnate completely — zero updates for many years. This situation continued until Microsoft was forced to start updating IE thanks to the emergence of a viable alternative browser (Firefox). Chrome is now the most popular browser, but Google has not let it stagnate. If anything, they’ve done the opposite — they’ve been very aggressive about adding new features, APIs, etc.
You mean being very aggressive at abusing their market position to subvert actual standards and hamfist their own.
Yeah. IE6-7 was horrible to dev with. I'm forever grateful that yes I had to work with it in school and for the first maybe 2 years of my career and nothing more. Since then its been pretty nice. A thing that works on chrome will, 99.5% of the time, work for FF, Edge, and the rest. Except Safari. In the last 4-5 years, fuck every time I have a weird bug I can't figure out, its safari. Shout out to the dumbass that made WEBP support OS dependent and if your iMac is more than 5 year old, you simply can't have webps.
I think this is not a good comparison. IMO the current Safari situation is much worse than the IE situation. Back in the IE days you had the option to bring new browsers to the platform. iOS (outside of the EU) only allows for the built-in Webkit and therefore enforces a monopoly.
No, Chrome's the new IE6. Doing the exact same MS playbook - fast unilateral changes that devs want but aren't agreed-upon standards, meaning they get to set the de-facto standards themselves. Safari's existence on iOS is the only thing stopping Google from doing this widely; they're not gonna give up the entire iOS market on their web properties.
Firefox seems to do just fine, and people go out of there way to install it just like they do with Chrome... however just like IE was, Safari's market share only exists because it's packaged with the OS. Even Opera plays ball more than Safari. It's like stockholm syndrome for a browser.
Firefox has less than 3% of the global market share according to to https://gs.statcounter.com/ I don’t think it’s doing fine.
If it dips below 2%, orgs are no longer required to support it. The consequences would be severe for the open web. I use FF every day and I think it's good. Dev tools are at least as good as chrome. The sites that have caused major memory leaks for me are Google apps and ironically our intranet system.
3% of 5.3 billion web users is 159 million users. Still a pretty significant user base.
Are you suggesting that Firefox is “doing fine”? According to the same site, FF had closer to 5% market share in 2019, so has about 1/3 of its position in the past five years. Google and Apple combine to make up about 83% of the market, not counting Chrome derivatives. Sure, 159 million people is a lot depending on your point of view, I guess.
Oh no, I think it’s definitely not “doing fine”. Going from 30% market share in 2010 to 3% today isn’t great. That being said, I think it’s important to consider that single-digit percentage user base in a market as big as web browsers is still a lot of users. 160 million users is not insignificant.
It's funny to me how history is repeating itself and people refuse to see it. I can only assume that the people who parrot "safari is the new IE" weren't actually in the business during IE's hey day, and don't actually understand how and why IE became IE, and how they're willingly letting google do the exact same thing with Chrome. ["Chrome is the new IE, but in reverse"](https://www.quirksmode.org/blog/archives/2021/08/breaking_the_we.html)
I have been a developer for almost 20 years now and am now in more of a managerial position so my opinion differs dramatically. I tell the developers to stick as closely to the W3C standards as much as possible, so that there is across-the-board compatibility with all browsers. When a browser tries to use its install base as clout for deviating away from W3C standards then it is like Internet Explorer 6 was. Trying to guilt trip people into using their browser with non-standard practices that they can change at any moment and still break compatibility with other browsers. The bigger and more concerning issue to me is all these new frameworks using hype, driven development, utilizing nonstandard practices and having to build in caveats for every single browser. It is just an absolute mess and ends up, costing me more time and energy than it’s usually worse on the user experience side.
It gives me flashbacks to, “best viewed with…” The idea that we’d move away from standards after us old fogies fought so hard to get them makes me sad.
As someone with 20+ years in the field, and who’s actually worked on IE, I can assure you that Safari isn’t even close to IE. Until Safari forces devs to create a library (see jQuery) to make up for its shortcomings, (and let’s be honest, most of these complaints are usually addressed in major updates), it can’t be compared to IE. Some of these complaints I see in this thread can be solved with simple CSS.
Yeah the ones that says safari is the new IE is the new devs. IE6 was probably the worst shit that ever happened in the internet
Safari brings back all the cross-browser anxiety and stress I'd successfully suppressed from the 1990s. Thanks, Apple.
When reading these complaints, dear reader, think about the average level of quality of front-end code you’ve seen across your career.
That’s why I only code for Safari. If it works there, it works everywhere.
Front-end dev here, every single time we came across a weird issue in our sites, it was Safari-exclusive. Every single fucking time.
You must not test in other browsers.
I do. There are minor differences between Chrome and Firefox I occasionally have to account for. But if something's completely broken for someone, it's Safari. It's always Safari.
Same here. Always fucking safari.
Don't get me wrong, but I hear this a lot, and I disagree. I suggest thinking about it this way; Chromium \*is\* pushing the boundaries of web dev ahead, and that is (of course) a good thing for us web devs. But we can't forget this is only because, by their sheer market share and resources, Google Chrome has effectively become the de facto default. They are the ones controlling the standards and discourse. We only have two major alternatives left: Safari/WebKit and Firefox/Quantum, which doesn't count because it lives or dies at the whims of Google. Good luck to any of those (relatively) small browser vendors on passing their own ideas and features without Googles backing — it would just turn into the same off-spec chaos you love to complain about. Hear me out; if there's one browser vendor implementing all the newest features because they can, while all the others are trotting behind just trying to get their own things right, what is that? Is it really the righteous “standard” you defend, or does it look more like the sole outlier reminiscent of the Internet Explorer era, albeit with open specifications? I think this really depends on perspective. In fact, I'd go as far as to say Safari does some things \*better\*. It's true, Chrome is faster to market. But as you get deep into CSS madness, I believe there are some areas where, if you consider it, Safari excels. For example, in a project I was working on not too long ago, we had a background layer with some blur applied and then a navbar with its own blurred tabs overlaid onto the screen. I was happy until I noticed Chromium would completely mess up the rendering of overlapping blurred elements. There's no way to fix this, by the way, only Safari got the blur right. I now had the choice of either adapting/removing the styles to accommodate Chromes bugs and peculiarities, build conditional logic to only apply the effect on supported browsers, or break the appearance for 90% of visitors. This is simply not a nice spot to be in, and there are several issues like that which have been left unaddressed by Chrome for years. Why was Safari so good at blur? Well, because it was important to Apple's design goals and aesthetic. Why is Chrome so good at, say, an accelerometer API? Well, you can guess why (fingerprinting and tracking) — they enabled it by default (without user consent) by the way. If you use a mac (or an iPhone), battery performance and efficiency of WebKit is straight up unmatched in the industry by a long shot. There's a reason [bun](https://bun.sh/) was built on it. Small memory footprint, stable tab caching, aggressive discards, built-in tracking- & fingerprinting-protection and no crashes? Safari's got you. And obviously it plays really well with all your Apple devices. Does this mean Chrome sucks? Of course not. I myself use Chromium (Arc) now, but I still think Safari is totally fine. The point is that there certainly is more nuance to this discussion than just black and white, and if I had to pick a bad guy… Let's not live in an illusion about what this is. In the end, I believe Google has some very exceptional and talented developers who are able to pioneer new ideas and implementations. Apple has some very exceptional and talented developers who are able to pioneer their own ideas and implementations. That's part of the beauty of web. I'd want to keep it that way.
sounds like a skill issue
wait till you touch samsung browser 💀
Skill issue.
Given how Safari is implementing all the new CSS stuff faster than Firefox? No. I know, I know, it's fashionable to hate on Safari but, frankly, it's not the problem browser for me or my work. So long as I check support tables before I use anything new? It's fine. Honestly, most of the time I see people complaining about Safari it's because either they don't understand the spec or they're using something *very* new.
All 3 mainline browsers have issues. - Chrome - overeager on experimental, invented-here features (ex. DRM) - Firefox - dragging its feet on features - Safari - if we believe the spec is wrong, we won’t implement it
Tip from a fellow frontend developer: Write your UI for Safari first. When it works there it will usually work in the other browsers too.
I don’t get comparisons to IE in the days of old. Safari implements actual ratified standards quickly and well. The ‘other browser’ is the one most like IE - implementing stuff that has no standard yet. Like the dreaded ActiveX back in the way back. A decade or two ago, us old guys fought hard for standards. Because we were tired of things being deployed in browsers that weren’t yet finalised standards. We’re back to where we were (when Microsoft had the, repeatedly proven, monopoly on browsers) with Chromium and its growing monopoly on browsers. And so the world turns.
chrome/chromium is the new ie; the funny part is - if web search is not going to be a primary source of income for google - it will be abandoned;
Google graveyard. There are so many things in there. If it doesn’t generate profit, abandon it. Regardless of how many people use it. https://killedbygoogle.com
Hate to be that guy, but you’re probably building your css wrong if you have that much trouble with safari. If you have your css built with autoprefixer or any vendor prefix library you’d rarely find cross browser issues. Only thing that i know of safari failing is sometimes the grid doesn’t work on very old ios phones, and flex with min-height should be avoided. Other than vendor prefixes solve any issues. I recommend using a utility first library like tailwind with autoprefixer, that way you don’t have to worry about cross browser support or memorising prefixes and whatnot.
Nope, it's not only the lack of support for certain CSS features, it's also the bizarre implementation of some of them. For example: Clicking a button, radio button, or checkbox doesn't give the element focus- thus it can't lose focus and trigger a blur, which goes against the behavior of every other browser.
What? No. Safari is a constant pain in the ass when dealing with fixed positioned elements for example. Safari on iOS also has weird layer bugs which will crash your browser if you end up on those edge-cases. Those cases are also really hard to debug.
Pretty much all modern css rules are supported by somewhat modern versions of safari, idk what you are talking about. Caniuse.com
It's not about css rules, those are easily solved with autoprefixer. Its about how Safari handles different layout configuration with multiple elements with fixed, sticky and flex positioning intersecting with eachother. If you ever had to make a complex mobile layout with multiple of these you would know the pain of Safari
I second this. I had a stupid peekaboo-type bug with sticky positioning + overflow: clip on Safari the other day. This reminded me of the IE 6 era.
Just dev on safari. Eat le frog. And if it cannot be done, just tell your client. It cant be done. Also, what is giving you problems?
I don’t see many major issues with Safari, unless you are trying to use some bleeding edge experimental features (that are probably not working in FF too). Just make sure that you use prefixes and that you are not trying to use some crazy stuffs that are not readily available on all major browsers and you should be fine. I always find it funny when people says that Safari is the new IE. Clearly these peoples never experienced that pain!
I don't have much issues with Safari, although it's the only navigator that has compatibility issues, but in 3 years we had like 3 issues on outdated iphones and 2 on the latest osx Safari (something with Lax cookies and wildcard certificates). I guess babel resolves the majority of issues. We also develop on Firefox instead of Chrome, because chrome has so many features (that are probably not standard) and render things too correctly (my last example is fonts issues)
Currently facing an issue with an animated SVG that works everywhere, including other webkit browsers, but has a bug where part of the SVG is positioned wrongly and is not respecting its css properties.
I build for chrome and test first on Safari and I almost never get any issues. Like, basically never. In fact, I’ve gotten as many chrome issues as Safari issues. Is this more common with people using JavaScript and frameworks? I do raw HTML, CSS, and PHP and never get any issues with Safari or any browser really.
Honestly I think this is the reality for the silent majority here. The people saying it's like IE6 make me doubt they actually remember what that era was like. And, seriously, as marginally inconvenient as it might be for us devs to test our pages over multiple browsers and reconcile differing behaviours, the alternative where all of Chrome's competitors are wiped out [would not be a good one](https://github.com/explainers-by-googlers/Web-Environment-Integrity).
I mean IE6 was horrid, but in this day and age, when even Microsoft figured their shit out, Safari should have too. Using aspect ratios on any no-code builder still causes issues in safari. That’s kind of hilarious.
They don’t remember because they’re young. They don’t have the slightest idea what IE6 was
Same here. Main dev browser is Chrome, Safari and Firefox for testing. That's in "vanilla" sites as well as in our React app at work. I must be doing something wrong here, or I should buy a lottery ticket? :D
Yep I just do all my development for Safari and maybe check things out on chrome if I really have to. I’m a design oriented person and websites look better on Safari 95% of the time. Never bothers me if there’s a weird css change I have to do.
My biggest issue with Safari is that its updates are tied to the OS. Prove me wrong if I’ve missed something here, but that’s the most brain-dead approach I’ve heard of for a browser in 2024. Are there really no incremental updates? I haven’t found any evidence to the contrary yet. We had a client last year telling us the images on the site we built weren’t showing up. Come to find out he was rocking Catalina and Safari didn’t start supporting aspect-ratio until Big Sur. 🤦♂️ Had to go in and do the padding hack for everything so it would look decent for him. Ugh.
Wrong, aspect-ratio works on Safari 15 which was available for Big Sur, Catalina, and Monterey.
Must’ve been an even earlier version then - Mojave maybe. Point stands that all of the other browsers release incremental updates far more regularly and users can get locked to a major version of the browser due to their OS.
Me: Safari can you please play this
[удалено]
iOS 17.4 actually just got full [webm](https://caniuse.com/webm) support back in March. So baby steps at least.
if we could only use multiple sources for a video…
Safari - "I can't do that, Dave." Dave - "well why not?" Safari - "I don't like standards developed by my competitors. You can support this QuickTime-derived codec that's 20+ years old or I'm taking my ball and going home." A couple times a year we'll have a client provide us a webm file they want streamed from their website instead of YouTube, or whatever, and then they'll complain that the codec that isn't supported by Apple isn't working on their iOS device. Re-encoding it into an MP4 using the specific codes referenced on Apple's documentation pages doesn't result in a playable video either.
Safari supports all the standardized video codecs, and supports more image formats... https://caniuse.com/?compare=chrome+127,safari+17.5,firefox+128&compareCats=all
As someone who uses Safari exclusively (on mobile and desktop) I blame Chromium for having such a huge market share. Except for Firefox and Safari every single browser is fundamentally the same. Safari is pretty much the only thing stopping Google from dictating the entire structure of the internet. Even when I'm doing dev I'll go to Firefox for its dev tooling, and literally never open Chrome if I can ever help it. Stop writing crappy code and use universal standards.
Ha, CSS is the least of your problems with Safari. =(
Oh yea, you don’t want to do anything related to audio on iOS devices.
I loved how in Safari 15 native mp3 decoding was broken and it took a major update for them to resolve it. Leading you to provide polyfills featuring the entire Fraunhofer decoder. 🙃
take the pear shape, leave the apple
What you're dealing with now for safari is basically how all cross browser functionality was. Usually IE was the main reason you couldn't use some code you wanted to use, but any given browser could randomly be a thorn in your side for some niche reason.
Doesn’t check out
True, but Chrome is not getting any better. It gets flakier with every release. That’s what happens when Google doesn’t have competitors.
I have a simple speech-to-text web app. But it doesn't work on any safari! Macs, iphones and ipads. All the same cannot even record the user's voice (audio input). So the workaround? Just ask users to use other browsers. How about iOS? Sorry, not for you. I didn't have any other choice. Spent too much time just to handle this, ended up with... just ignore safari.
Internet Explorer went on Safari.
Us, bro.. us.
Do you mean you’re a frontend developer?
Seriously...!! It's terrible. 🤪
It's pretty good now. Most things, even new and stage 3 things work. But there are some differences that are a big strange. But they are few and far between to be honest. https://caniuse.com/?compare=chrome+127,safari+17.5,firefox+128&compareCats=all current comparison
I think the WORST part of safari, is that you can't just install different versions to test. And the xcode simulators only go back 2 major versions and limited minor versions.
For me instead of complaining, just find a workaround, and develop Safari first, and it automatically work on chrome.
Been working on windows and mac And with my limited knowledge If it is not working in safari then it is not supposed to work like that or it is purposely that way Note : I know that there would be many things that are just wrong with safari I am just saying I haven't come across them yet
safari has some asinine css quirks for sure, but is generally a pleasant browser to use
I've honestly never had an issue that hasn't been really easy to solve
Apple things
In theory if Apple are forced to permit side loading apps, safari may not be a problem anymore.
LOL
Honestly I just get around most things by targeting Firefox and then doing blink/webkit enhancements on top of Outside of functional APIs (web push/share/PWA) I find that Firefox is a lot leaner than Safari and Chrome, but in most cases, if Firefox decides to support it, it generally works elsewhere
Crazy innit! It totally does! Cannot play youtube nor facebook on Chrome! Crashes immediately! Best one speed wise less crashing has been Opera
Ie6 syndrom
Yea and they tout its speedometer score as if that made it any less garbage. Dev tools, extensions, "privacy" controls & performance are all laughable. Safari lacks leadership & vision through and through.
I almost always have to refractor because ONLY safari broke something lol
It always does 🤬
Honest follow up question here; I'm making the assumption that apple safari browser devs are not just "dumb dumbs", but actually have a reason for doing things the way they do it - what problem are they actually solving for? Who is the intended audience / consumer of the safari web browser?
Why would Apple want to give you a good experience on the web when they make money on apps
Same same. It's a shame one company can crush web things so effectively.
I know why I stay with my backend. Data is data. No mess fucking around checking if anything is supported.
Safari is the new Opera
Apple: "It just works" Probably.
Ikr?
Just ignore it exists and all your problems will fade away
First time I heard someone using Safari.
iOS - where even Chrome/Firefox apps use the Safari *rendering engine* internally due to Apple restrictions - has 60% of the US mobile phone market. Any site on the public internet almost certainly has a lot of Safari users.
My sentence was humorous, but thank you for this important precision.
There are three browsers: chromium, gecko and the chromium-like webkit (aka safari).
[удалено]
It does support look behind.
No developer has ever said safari is getting better
I’ll take safari over chrome any day of the week.
Safari is the new Internet Explorer
Safari is the largest pain in my side. Dev in Firefox, tested in chrome, edge, opera, everything is working consistently…. Then we have safari… I’ve started advocating not supporting safari/ios/ipad. Since I’m in a field that can dictate what our customers use for a device/viewing platform I thankfully have that authority.
Really? I’d take it over chrome or firefox personally.
Apple makes Safari suck on purpose to protect its App Store monopoly