^ This, 100%. Chrome is by far the bad actor, and not only that, Safari is arguably the better browser even if strictly looking at "support for web standards" (but in many other ways as well).
The vitriolic hate it gets in many threads are completely misguided and likely the result of years-old opinions on it. In the last 3 years Safari dramatically accelerated development, leapfrogged Chrome in performance to a staggering degree, and basically became close to an ideal browser.
And nearly every so-called standard people point to to "prove" Safari is lagging behind is almost always just something Chrome pushed out without any consensus.
It's funny because I think the hate comes from Webkit being forced on iOS, but it often comes out as "Safari sucks it's the new IE" which is pretty much the opposite of true and undermines the point.
Safari used to be "the new late-IE" a few years ago. It lagged significantly behind other browsers and it kept intentionally holding back support for open standards and codecs, forcing websites to make Safari-specific workarounds whenever you wanted to do basic things (I had to write scripts to transcode Vorbis to MP3 when deploying a web game just so it could have sounds on Safari, for example).
These days Safari gets better indeed (through it's still a PITA in some areas), while Chrome is clearly "the new golden-days-IE" - which long-term is probably much worse than Safari could ever be.
As someone who grew up with mp3s, your example seems interesting because it seems like an example where you had to encode from something obscure (ogg) to the closest thing to a “universal” sound format as wav could be: MP3.
In that case doesn’t it seem like Google took an ideological stance by choosing a non-patent-encumbered codec instead of supporting mp3? And they could do it because of their dominance? Or is that not accurate?
Vorbis was ubiquitous on the Web way before Google had such influence over it as it has today, and MP3 was absolutely nowhere near universal. Firefox did not support MP3 for a while, and even once it did it relied on system codecs - and many distros didn't ship with MP3 support by default until its patents expired a few years ago.
Choosing non-patent-encumbered codecs for open standards is as much ideological as practical.
I’ve never seen Vorbis and ubiquitous in the same sentence. Besides Mozilla, who had Vorbis native support in their browser?
In practice, MP3 has had support on every platform since the mid 90s. I could probably count the number of times I’ve come across an ogg file being distributed on one hand.
> Besides Mozilla, who had Vorbis native support in their browser?
Pretty much everyone who implemented HTML5 audio for a few years, while MP3 support in the browser was initially barely heard of? Mozilla, Google, Opera, KHTML, WebKit... Safari and IE were the only outliers, and had tiny minority of market share for a while (not counting versions that didn't support HTML5 audio at all). Today only mobile Safari is still an outlier.
You couldn't use MP3 without Vorbis fallback on the Web for about a decade. Whenever you played audio in the browser without using Flash on anything else than iPhone, chances that it was Vorbis were very high for a good while. YouTube used it in WebM before switching to Opus. In fact, even AAC gained reasonable support on the Web earlier than MP3 did.
In practice, although very popular, MP3 was nowhere near universally supported until just a few years ago. I know that pretty well - I have posted patches to some projects that enabled MP3 support once its patents expired myself; I've also used to maintain websites based on HTML5 audio since 2009.
Non-patent-encumbered and standard are not the same thing at all. Platforms do not want to ship support for esoteric formats, and will fight back against adding anything not needed for long-term interoperability - for examples, see JPEG XL drama lately in Chrome.
This is for maintainability/security surface reasons as well as patent risks, as open/closed and standardized/bespoke axes have nothing to do with whether or not something is patent encumbered.
I haven't seen anyone re-evaluate it since Safari added Web Extensions on Mac and iOS a few years back.
Most likely not for same reasons ad blockers were freaked about Chrome's Manifest v3 push - browsers are trying to optimize away the latency from a massive synchronous javascript-based list check on page load, and the privacy risk that comes from these extensions having exposure to every page (and injecting their code into every page). Conversely, the web extension authors don't see the set of limitations as feasible.
But it is odd that uBlock Origin doesn't seem to have even issued a public-facing statement of even evaluating the functionality that is there in Safari.
No. Apple doesn’t let plugins hook in so much because the plug-in ends up seeing a ton of data about what the user browses, and they can slow the browser down if badly written.
Apple lets plugins provide lists of elements/css/IPs/etc to block. Safari processes them and is able to block stuff based on that extremely fast and power efficiently.
There is flexibility lost. Plug-ins can’t see which rules are/aren’t hitting. You can’t filter based on the content of a request.
So there are ad blockers, and they work well. But uBlock, as it works elsewhere (I know it’s considered the best), isn’t possible due to the trade offs Apple chose.
This isn’t true anymore, there are numerous ad blocking plugins that do the extensive blocking just like uBlock. May not be as good due to less active community, but the capabilities are there and a few of them are quite good.
Many forget that Microsoft was introducing many incompatible standards, and only let IE stagnate after they won over Mozzilla.
Safari isn't the one turning the Web into ChromeOS.