Hacker News Reader

Comment by kouteiheika | Hacker News Reader

Speaking from personal experience as a developer (although YMMV) - this is totally true.

And I'm not even talking about some newfangled APIs like WebUSB and such (I don't really care about those personally). Safari's handling of regular HTML + CSS is regularly broken compared to other browsers. (At least in my experience.)

Open the site in Chromium. Yep it works. Open the site in Firefox. Yep it works. Open the site in Safari. Ugh... it's broken.

That's something that I encounter on a regular basis.

It's really inexcusable that Apple, being the richest company in the world, has a web browser that's this bad. But they don't really have any incentive to do better. Thanks to their walled garden the only available web browser on iOS is Safari, and since no developer can afford to ignore iOS as a platform they have no choice but to deal with it.

View on HN

Open the site in Chromium. Yep it works. Open the site in Firefox. Yep it works. Open the site in Safari. Ugh... it's broken.

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.

History is just repeating itself. If you capture enough browser market share, there is no incentive improve handling of web content that does not materially help the bottom line.

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.

Apple _does_ put 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.

You’re talking as if it’s an either/or situation. For a company the size of Apple it definitely isn’t. They could fix long-standing bugs, implement web standards others have had for years and improve security, privacy and battery life. They just don’t.

Not necessarily. There are “web standards” pushed by Google that are inherently inimical to increased privacy and cannot be implemented with sufficient security for a billion devices. I have to use Chrome and Chromium-based browsers for a lot of what I do, and the very first thing I do when I have to set it up or configure a new profile is _disable_ crap like:

- 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.

I feel like Web USB and Web MIDI always come up in conversations like these and I don’t think I’ve ever met anyone that cares too deeply about either. Don’t get me wrong, I know there’s a market for them, but in the context of this conversation they just feel like diversions.

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.

To pile on, several other APIs have little or no privacy issues, when done right.

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.

I don't agree. Microsoft seriously tried with Edge, but the pace of change set by Chrome was too much for them. The only group even close to keeping pace with Google is Mozilla—and their market share numbers are starting to look concerning. Given the current trajectory, we can't place long term hopes in Mozilla.

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.

Apple chooses not to keep up. They obviously would have the resources and technical competence to do it if they wanted to.

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.

> Apple chooses not to keep up.

Is that an opinion or do you have insider knowledge?

The level of profit Apple achieves every year is public, not insider knowledge. They could very obviously hire some more engineers to work on WebKit without bankrupting themselves.

> Apple _does_ put effort into Safari.

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.

> Security, privacy, and battery life sell phones.

Because that's what people want.

No they want Security, privacy, and battery life. Yes, I know there's no difference to the quote (copy&paste). The difference is that what Apple says is security and privacy is often fluff and done for PR and isn't actually what people want when the say they want security and privacy. Look no further than what Apple call end-to-end encryption in iMessage. It is on par with VW saying their diesel engines had such and such emission when in reality they both have huge and multiple asterisks.

> The difference is that what Apple says is security and privacy is often fluff

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.

Sure, let's have competition in the browsers on apple platforms then? Let the User choose what they want?

I think you misunderstood what I said.

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.

Hey, IE6 had PNG alpha, as long as you did some black magic to your PNG files to make the alpha work, which is really the story of IE6.

> Thanks to their walled garden the only available web browser on iOS is Safari, and since no developer can afford to ignore iOS as a platform they have no choice but to deal with it.

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]."

If enough developers start removing features for Safari this could actually have an impact. I would consider this even if it would harm the bottom line of my business. Simply because it removes stress and frustration in the development process.

This has been my experience over the past several years as well. My particular issues have been with the Canvas element and with SVG support (which is insanely buggy - even the dev tools are bugged) but there are also occasional layout issues.

I definitely feel like comparisons to IE are apt.

> and with SVG support (which is insanely buggy - even the dev tools are bugged)

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.

Broken HTML+CSS in Safari? Examples?

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.

> Broken HTML+CSS in Safari? Examples?

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.

I have <div> elements with background-image assigned via CSS. Those divs require different CSS settings to get the height to layout correctly that FF/Chrome do not need.

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

I'm constantly having to add `translateZ(0)` to elements to get them to handle z-indexing or overflow: hidden correctly in Safari.

Here's one I encountered while developing: Safari doesn't handle linear-gradient with transparency like all other browsers: https://stackoverflow.com/questions/38391457/linear-gradient...

There's the scroll background jank due to their scroll snapping model (you can scroll below a full screen div which should be impossible), the various zIndex jank, round corners for video, the SVG background issues (and SVG in general are buggy), the input autocomplete issues with their half-broken password manager... And that's all present on the latest iOS.

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

When 3d rotating absolutely positioned elements that lie over each other, Chrome/Firefox/IE will display elements in their entirety on top of each other. Safari gets them to intersect with each other in weird-yet-mysterious ways that I've never been able to fathom[1].

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 think you are missing the point. The reason you don't see broken sites is because developers take extra time making sites work in Safari. They shouldn't have to.

>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.

I always think this is odd. If Safari is as dire as people say then why not just develop in Safari first? If your site works there then it’ll just work in Chrome/Firefox/Edge right?

This argument applied similarly for IE6.

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

That's exactly what I meant. You were forced to do extra work to support mobile Safari or else exclude Apple customers. That decision is made over and over again by teams everywhere and Desktop Safari reaps that benefits.

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?

Safari didn't repaint scroll-attached linear gradient background on container content change (thus resized). If you don't also recreate the container. Your background is going to be screwed.

Our site broke in Safari because Safari handles dates (as in the built-in Date object) differently than all other browsers, so it's not just styling or visual things that can be different.

Differently in what way?

Safari handles date only time different to other browser (the time zone). Your date is going to be off by <time zone> hours if you don't append a timezone on it to force it parsed correctly.

Reply on news.ycombinator.com