This is unacceptable from professional developers. Progressive enhancement is a thing.

Apple announced at last year’s WWDC (https://developer.apple.com/wwdc20/10663) the areas where they improved interoperability with other browsers and that Safari passed 140,000 interoperability tests:

We made a really big effort this year to improve Safari's interoperability with other browsers. One way to measure that is web platform tests. It's a set of tests used by browser makers to ensure interoperability, so your web content operates the way you expect across browsers. So I'm pleased to announce improved interoperability for service workers, XHR + Fetch, pointer events, CSS, SVG, web assembly, and many more areas. Safari passes a hundred and forty thousand new interoperability test cases this year.

And you can look forward to continued progress in this area.

IE gave us wonderful features (XMLHTTPRequest) but as soon as MSFT found they had a monopoly, development stalled and the world got stuck with IE6, which lacked even basic features like PNG image alpha transparency.

When/if a court orders Apple to allow alternative web engines on iOS, and they start losing market share to Firefox, Chrome or Edge because they are including features that Safari does not, Apple will finally put some effort into Safari.

It’s just not on the parts that you and other developers want it to be on. It’s definitely on the parts that I (as a user) want it to be on (security, privacy, and battery life in roughly that order).

It is unlikely that a court will be able to force Apple to expose OS APIs that would allow for the insecurity of WebUSB or WebMIDI on iOS, even if they do force other engines. And that’s a good thing.

- Web USB - Web MIDI - Web HID - Web Push - Web Motion Sensors - Site protocol handlers - Web Serial Ports - Web local file editing - Payment handlers - VR - Attention

That is, I make it so that sites aren’t even allowed to ASK me for those permissions. I know that a regular did a Web MIDI site recently that is sort of neat, but the protocol is essentially impossible to secure.

Each and every single one of those things provides additional security risk, fingerprinting opportunities, and privacy leaks BY DESIGN, and I can’t ever see turning them on.

When I talk about Apple dedicating resources to Safari I mean that IndexedDB was broken for years. And was broken again just last month:

https://www.theregister.com/2021/06/16/apple_safari_indexedd...

This isn’t engineering that priotisises battery life. This is flat out neglect. Aren’t there unit tests for these kind of things pre-release?

I don’t want to be able to interface with a MIDI keyboard on my site, I just want to be able to store data reliably.

Push notifications: no, obviously I don't want seo-loaden-adwords-stuffing.blog to send me push-notifications. But I do want m.twitter.com, weatheralerts.app or m.issuetracker.local to send me those. I don't want cdn.random-ad-network.com to read my location. But I do want weatheralerts and publictransport.planner to read them. bird.watcher is free to use my camera and littlealchemy.app is free to use localstorage.

Apple decides for me that I don't want this. Protecting users' privacy would mean research and innovation in how to make those choices. Anything from centralised whitelists to better UX for those permissions. Apple invests in none of these and instead denies it to all.

If neither Microsoft nor Apple can keep up, and the Hacker News crowd thinks that's okay, we might as well give up on the notion of an open web and rename it the Chrome Platform.

But cui bono? Apple benefits directly from crippling the web since it protects their App Store monopoly, they happen to have the perfect means of crippling the web by ensuring there will be no browser competition on iOS, and it is the area where theyre shipping their worst software. It is hard to believe that it is a coincidence rather than a cynical corporate optimization game.

Is that an opinion or do you have insider knowledge?

I did not say they did not. What I said was...

> that does not materially help the bottom line.

Security, privacy, and battery life sell phones. Better PWA and WebRTC would cost them money because those modern Web technologies compete with the App Store.

Because that's what people want.

In the context of Apple's Safari engineering priorities, which is the context of this discussion, Apple has delivered real security, privacy and battery life wins. This isn't even disputed by Apple's detractors.

Even if a court does something like “you must allow alternative browsing engines”, it’s going to be a very difficult thing for a court to rule _successfully_ that “you must allow unrestricted USB access to alternative browsing engines”, as that will completely destroy security.

It’s also what would be required to make people who hate Apple for not implementing the same privacy-busting and security-nullifying APIs that Chrome has done.

As the sole developer and maintainer of a Javascript library for working with the <canvas> element, most of the problems I encounter when working on the code are to do with things which work fine in every other browser, but die in flames on Safari.

I'm getting to the stage where dropping support of the Safari browser (and thus all iOS browsers) is something I consider on an ever-more serious basis. One of these days I'm gonna add a big banner message to the library's website stating: "If you need your canvas to work on Safari/iOS, try coding it using [list of competing canvas libraries, with links]."

I definitely feel like comparisons to IE are apt.

I ran into this on a project a year ago, where our app was completely and critically fucked on Safari with no obvious path to fixing it, short of tearing out a ton of custom data visualisation stuff based on SVG and rewriting it from scratch to use a whole different approach like canvas.

It's one thing to have a rendering bug like Chrome had with flex box a while back where it would stretch elements vertically in certain situations against the spec, there's enough ways to do things in CSS that that can be worked around with a bit of tinkering. But when you've got a rendering bug and the dev tools doesn't accurately represent what's being rendered, it leaves the developer in a terrible situation where they're stuck with a black box with a broken interface so they can't even tell what the true result is, let alone see the inner workings.

I was lucky we only had 5-10 people trying to use it on Safari and I could just say sorry and recommend Chrome. But I can't imagine how frustrating a similar situation would be with a large number of users.

I started using Safari as my daily driver because I use all apple devices and I like extending my battery life. Before deciding that, I did stints with Firefox and Brave, both of whom had poor sync'ing.

I can't remember the last time a site had broken HTML/CSS with Safari. My impression is the desire to have good mobile support keeps Safari support alive.

I think I encountered more broken CSS when I was using Firefox.

If Safari recognises and/or honours the backfaceVisibility CSS property, then I've yet to implement it correctly on a web page[2].

Safari doesn't allow SVG filters to be applied to <canvas> elements[3]. Applying SVG filters to other elements is (I think) fine.

Talking about Safari and the <canvas> element, Safari will show an italicised text (ctx.font = "italic 12px Arial, sans-serif") to be stamped onto the canvas, but emboldened text (ctx.font = "bold 12px Arial, sans-serif") displays as normal, non-bold text. If you want bold text to show in a canvas element on Safari, you need to use a specifically emboldened font.[4]

... the list could go on (and on) ...

Examples

[1] - https://scrawl-v8.rikweb.org.uk/demo/dom-002.html

[2] - https://scrawl-v8.rikweb.org.uk/demo/dom-008.html

[3] - https://scrawl-v8.rikweb.org.uk/demo/filters-501.html

[4] - https://scrawl-v8.rikweb.org.uk/demo/canvas-016.html

I didn't mean that as "broken in the wild". I meant as "broken when I'm actually developing a website".

> I can't remember the last time a site had broken HTML/CSS with Safari. My impression is the desire to have good mobile support keeps Safari support alive. I think I encountered more broken CSS when I was using Firefox.

You're not seeing broken websites on Safari because everyone's forced to test (and fix!) their websites for Safari due to its market share.

On the other hand Firefox's market share is relatively low, and dwindling day-by-day, so there's less incentive for everyone to actually test and fix Firefox-only issues.

That said, I use Firefox as my main web browser, and personally I find it very rare for something to be broken under it, even when it's not officially supported. It probably highly depends on which exact sites you visit though.

Those same divs have border-radius applied, and are nested in another div with overflow:hidden. In FF/Chrome, the image scales as one would expect. In desktop Safari, during the CSS transition, the border radius of the overflowing element goes away and the element with the scale suddenly has square corners outside of the overflow. Once the transition ends, the corners disappear again.

This is on the Safari Technology Preview version

>My impression is the desire to have good mobile support keeps Safari support alive.

I would very much argue the opposite. A good browser in iOS is directly against what Apple want (people in the app store, not in browsers). Safari is at best the absolute bare minimum a company like Apple can get away with and not a line of code more. Having just redesigned our business site I have just finished fixing the site to be the same in Safari as in the other browsers. I was forced to do this extra work to not exclude Apple customers but if I could have left it as is I wouldn't have wasted my time.

The technologies I want never actually "win". I always have to choose the one that I either hate the least or has some other compelling benefit. The latter is the reason why I'm using Safari.

I'd rather Safari come around (or be abandoned), but pressuring Apple this way is not very effective. How long did they hang on to those stupid butterfly keyboards?

Like IE6, Safari is not a normative subset of web standards.

Recently they also broke localStorage & indexDB which are core features of the web (sill broken on the latest stable)