Wait until Google implements something and shoves it down everyones throat in Chrome and then has all the Google fanboys claiming that its the best thing since sliced bread and thus should get implemented by every other browser just because Google did it?
That's how we ended up in the situation where Google shipped U2F, sites implemented their implementation and then when the standard WebAuthN was built it was not compatible so sites had to be updated to be standards compliant, and it took a while to do so.
Or when Google added WebP without clear consensus. Or when they added FLoC or Topics API, or whatever else they have cooked up. Or things like WebUSB, WebMIDI and others?
There's a glut of Chrome only sites out there, and it continues to grow as web developers test just on Chrome but not the other browser engines. It's turning into the next IE 6, I remember the time there were a lot of "Made for IE 6" logos and graphics on sites and they did not render well or at all in Netscape.
As much as the locking down of iOS is annoying for everybody technical, we should be somewhat thankful that Apple has ensured a large population of mobile safari users.
That's a pretty poor comparison, a lot of the Android vs iOS debate is more akin to buying a sports car and then finding out it won't go more than 50km/h outside of your own country.
Back before flagship prices inflated (due to Apple) people buying a $1k iPhone couldn't do something as simple as use a different keyboard. And of course the product is advertised as advanced tech, yadda yadda.
There's been a spate of things, custom keyboards, wallpapers, multi-tasking, installing apps from a store rather than built-in, home/lock screen widgets, default apps for certain files, PiP, app drawer, and so much more.
I don't consider companies being inspired by/adding features from the other, it's not theft when it's a good idea (unless it's Apple's, then you get sued). But for them to market the way they do while taking so long to add basic things like these, it's just ugh.
Keeping in mind, of course, there are plenty of people who won't turn off the TV because there's nothing on that they want to watch; they'll just pick the channel that is the least bad.
Except in every thread about iOS or Safari are a ton of people crying for real Chrome on iOS because Safari is the new IE 6 holding the web back by not implementing the new WebDogCam4 “standard” Google pushed out 2 days ago.
^ 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.
Nope. Not at all. I think they’re doing great. Most of the stuff I see complain about here on HN are features I’m not sure should exist (web push notifications, hardware access), uBlock (there are other options), and some PWA stuff they’re doing but I do t think there is anywhere near the call for from users some developers think.
If Safari was as bad as so many claim it would have next to no desktop market share. But despite Google pushing Chrome at every opportunity tons of people like my self prefer Safari.
Apple has different priorities for Safari than Google does for Chrome. That’s fine. My priorities match Safari far better, I’m perfectly happy with how they’re doing things.
This is something that lots of people complain about but somehow I never experience. Not to doubt it—I’ve seen the complaint enough that I believe it—mostly I’m just confused as to how I’ve managed to dodge the problem.
Firefox and mobile Safari, so I guess I should experience it…
Hmm, many google web features not-so-subtly nudge you to install Chrome. Some outright block usage of anything other than Chrome. This has been going on for well more than a decade.
I regularly see small/medium websites which state they only work with Chrome, but I feel they do so at their peril.
I see some of those sites push people to install a "desktop app" if you do not use Chrome, which is of course an Electron-based app.
I also regularly see services that just fail for long runs of time on non-Chrome browsers due to complete lack of regression testing, or (slightly more generously) because they aren't testing their services against current releases of Firefox/Safari. Safari is more sensitive to this, both because of a much more active development tick compared to Firefox, and because it is leveraging system frameworks rather than a relatively static compatibility layer 'buffer'.
That's how nearly everything that is now a web standard came about. The web standards groups generally don't want to even consider something for standardization until someone has actually implemented it and deployed it.
It doesn't require them to be inflicted on all of the internet. And it most definitely doesn't require you to go ahead and redirect a huge chunk of ad income to yourself while "processing" the standard.
This is somewhere between anti-consumer and stealing.
> It doesn't require them to be inflicted on all of the internet. And it most definitely doesn't require you to go ahead and redirect a huge chunk of ad income to yourself while "processing" the standard.
I can't quite figure out who or what in particular you are talking about.
If the original topic, Apple/Safari do not charge for private click measurement, and Apple does not have any significant advertising platform for the web.
There are other more controversial uses of the technique - mobile game SDKs used tracking identifiers and other techniques to try to measure conversion and associate it to a persona, which Apple shut down with ATT. Apple added a PCM-like technology at about the same time so that advertisers could get broad metrics on advertising programs and conversion.
This is different/separate from more controversial uses, such as blocking in-app advertising/install conversion metrics and persona building. There, Apple _does_ have some competing interest in terms of the App Store ad platform.
No they wouldn't. I can't think of a single thing in any browser that was implemented after a standard was created. It's always been driven by one browser just doing a thing, then other browsers do it slightly differently, then the standards body comes together and they settle on the-one-true-way and everyone updates their support to match the standard.
It very much used to work like this, pretty much exclusively.
More recently, though (especially, the last couple of years), browser vendors work very closely with standards groups, contributing there, and looking for feedback from other browser vendors. At least in the CSS and JS space, the extensions to those standards have proceeded largely as a group effort rather than as you described.
There's pretty much always implementations, but it is a huge headache when people rely on behavior which is not yet stable.
The browsers have started to first ship things behind feature flags, and in Chrome's case also behind "Origin trials". We just have less need now for one browser to go off and define their own way for borders to be drawn as rounded rectangles.
I suspect we'll see some funky CSS extensions ship pre-standardization for VR headsets, though. Things like controlling the z-axis height of <dialog> and other elements.
