Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Too lazy to look at the reported issues in this forum? Easier to switch browser than doing free QA work.
I’ve been following this thread from the start. NONE have been posted that are actually broken when viewed from my devices. If I was the one saying “SITES ARE BROKEN IN SAFARI” I’d at least have one example on the off chance that someone said, “What site is broken?” I mean, it’s not an insane question.

But, if I made the statement understanding that I didn’t have an example, if anyone asked, I’d have a snarky answer ready to redirect the focus from the fact that I don’t have an example of a site that doesn’t render properly in Safari. I think. Maybe.
 
I’ve been following this thread from the start. NONE have been posted that are actually broken when viewed from my devices. If I was the one saying “SITES ARE BROKEN IN SAFARI” I’d at least have one example on the off chance that someone said, “What site is broken?” I mean, it’s not an insane question.

But, if I made the statement understanding that I didn’t have an example, if anyone asked, I’d have a snarky answer ready to redirect the focus from the fact that I don’t have an example of a site that doesn’t render properly in Safari. I think. Maybe.
The most significant example for me is my school's learning management system - Canvas by Instructure. I'm not exactly who to blame, but many instructors have submitted a ticket to Instructure to fix problems on Safari.

Instructure developers have not come up with a way to fix this ever since Safari 13.0.

For example, on Chrome:

1646003970162.png


On Safari, the exact same webpage. You can see that a simple line divider on Chrome shows up as a broken image on Safari.

1646004040189.png


The school has officially stated to avoid Safari for using our LMS site. There has been cases where quizzes did not display images required to answer the question via Safari. For students who are already stressed, they might freak out. Obviously, this can be easily fixed by switching to Chrome. It sucks that I have to switch browsers mid-way because I forgot to start the quiz via Chrome and not Safari.

Instructure's comment for Safari is this:
Note: Safari 13.1 and later versions contain an update that may cause issues with downloading files, displaying images, and playing chat alerts in Canvas. Canvas engineers are currently working on a solution for this issue. Until then, you may avoid errors with files, images, and alerts by disabling cross-site tracking prevention in Safari when using Canvas. If disabling cross-site tracking doesn't resolve these issues, please try one of the other supported browsers.

The Safari browser does not provide an option to allow third-party cookies from specific sites. Instead, Safari users must go to Preferences and then to the Privacy tab and opt whether or not to block all cookies. Changing this setting affects Safari's treatment of cookies on all sites. Using a browser besides Safari is recommended when using a tool that is integrated with Canvas.
Disabling cross-site tracking no longer works. Instructure's full report on Safari's issues with it is here. The reason why this website is significant is that many students use Canvas and many students have Macs, at least in the States. It's kind of annoying having to switch browsers just for one website.
 
Last edited:
The most significant example for me is my school's learning management system - Canvas by Instructure. I'm not exactly who to blame, but many instructors have submitted a ticket to Instructure to fix problems on Safari. Instructure developers has not come up with a way to fix this ever since Safari 13.0.
Canvas says that they are compatible with Safari and that they’re working on a fix, so at least they’re not saying “just use Chrome because Safari is the new IE”. I’m guessing most examples may be in the LMS area, actually.
 
I'm no pro and only switched to Mac in 2017, but it works fine for my needs usually. Sometimes sites wont open though. IE frustrated me.
 
Macrumors needs a new news article as the Safari Team is involved in this new effort to improve anything using webkit.


Apple has partnered with Google, Microsoft, and Mozilla on a new endeavor to improve the interoperability and user experience of their web browsers.

The group are working on a new benchmark dubbed Interop 2022, which will "improve the experience of developing for the web in 15 key areas." Along with the browser makers, software consultant groups Bocoup and Igalia are also on board.

All four of the browser makers have agreed to focus on the 15 areas, which will include cascade layers, color spaces and CSS color functions, new viewport units, scrolling, and more. The project will focus on the four browsers involved: Safari, Chrome, Edge, and Firefox.

"For the first time ever, all major browser vendors, and other stakeholders, have come together to solve the top browsers compatibility issues identified by web developers," the group said in a blog post.
The end goal is to make web applications look and function similarly on different web browsers, which isn't the case currently. The goals are also all design-focused, meaning that browsers have an incentive to participate alongside their rivals.

"All of these technologies are important to Apple and to everyone working on WebKit. We care deeply about the health of the web, and interoperable implementations of web standards," Apple said in a statement. "We welcome collaboration with our colleagues in the many web standards organizations, and in Interop 2022 to make the web as interoperable as it can be."
 
Macrumors needs a new news article as the Safari Team is involved in this new effort to improve anything using webkit.


Apple has partnered with Google, Microsoft, and Mozilla on a new endeavor to improve the interoperability and user experience of their web browsers.

The group are working on a new benchmark dubbed Interop 2022, which will "improve the experience of developing for the web in 15 key areas." Along with the browser makers, software consultant groups Bocoup and Igalia are also on board.

All four of the browser makers have agreed to focus on the 15 areas, which will include cascade layers, color spaces and CSS color functions, new viewport units, scrolling, and more. The project will focus on the four browsers involved: Safari, Chrome, Edge, and Firefox.

"For the first time ever, all major browser vendors, and other stakeholders, have come together to solve the top browsers compatibility issues identified by web developers," the group said in a blog post.
The end goal is to make web applications look and function similarly on different web browsers, which isn't the case currently. The goals are also all design-focused, meaning that browsers have an incentive to participate alongside their rivals.

"All of these technologies are important to Apple and to everyone working on WebKit. We care deeply about the health of the web, and interoperable implementations of web standards," Apple said in a statement. "We welcome collaboration with our colleagues in the many web standards organizations, and in Interop 2022 to make the web as interoperable as it can be."
Even though this is likely to end up with the old XKCD situation of “one more standard”, it’s a far better solution that what web developers want, which is the entire internet using the same browser renderer.
 
WebGL isn't under "experimental features" in Chrome. To disable it, you need to open Chrome with "chrome.exe -disable-webgl".

FWIW, my group was using Foundry VTT when we were struggling with Safari support of WebGL. It is a common virtual table top system for role playing games (like D&D). I'm not saying that WebGL is some singularly important web standard. It was just one example of a standard where Safari support lagged the competition.

To be clear, as of October of last year, Safari began full support of WebGL again (including 2.0). From mid-2020 until then, it kind of worked as an experimental feature.
For what it’s worth, there’s a difference between WebGL and WebGPU. WebGL is tied to OpenGL ES, which is deprecated on Apple’s platforms in favor of Metal. (And OpenGL doesn’t seem to be long for the world, with the rise of other low latency graphics systems like DirectX 12 and Vulkon.) WebGPU allows for OpenGL and OpenCL style GPU access on Metal, Vulkon, and DirectX 12, and it’s considered the way forward. WebGL is deprecated, to some extent. And, according to the official implementation page hosted by the WebGPU working group on GitHub, no browser has it active by default (it’s hidden behind a flag on Chromium, an about:config pref on Firefox, and the Developer menu on Safari Technology Preview). https://github.com/gpuweb/gpuweb/wiki/Implementation-Status

That’s actually a legitimate issue with standards compliance today and the concept of the living standard. If you invested development time into support for SPDY that couldn’t be re-engineered into support for HTTP2, then you wasted time chasing after a shifting standard. There’s been a lot of pressure within the web standards community to move quickly (to prevent a stagnant period like the IE ascendancy and HTML4’s stagnation), but the downside of that is that the standards bodies have been quick to adopt new standards and browsers have been quick to adopt new de facto standards that are quickly (5 or less years, or so) deprecated in favor of newer, theoretically better approaches to the same issue. Maybe web developers like this state of affairs because it affords them greater job security, but I’d hate to spend the effort getting on a new test framework only to have support for it pulled out from under me less than 5 years later.

There’s also been an issue of web standards by force where Google, in particular, pressures for self-serving standards (some of the progressive web app standards only really make sense in the case of an OS like Chrome OS). Instead of IE’s old de facto standard days, Google tends to force its de facto standards through the standards body. Stuff like WebUSB only makes sense for Chrome OS, and vendor specific stuff like that shouldn’t be allowed to pollute the general body of web standards. Maybe shunt them off into a Web Operating Systems 1.0 standard.

Edit: As an additional note, there are a lot of potential security issues WebGPU (and even WebGL and WebCL) expose, least of which is drive-by crypto mining on users’ GPUs. (The WebGPU team specifically notes that you shouldn’t browse the open web with WebGPU support turned on because of security concerns.) It’s probably a good idea to avoid using it, unless your application 1) absolutely needs to be a web app (or at least makes more sense as a web app than as a local app), 2) absolutely needs the functionality they expose, and 3) can guarantee that it’s running in a tight sandbox and not on the open web (ie a Chrome OS application that’s locally installed instead of being on the web or an Electron application installed to users’ desktops).
 
Last edited:
  • Like
Reactions: Unregistered 4U
At this point I beleive it is a waste of money and resources for Apple Inc to devlope their own web engine, considering most sites are optimized for Chromium web engine. It would make sense for Apple to take Microsoft‘s playbook and make a privacy focused Chromium browser.
 
  • Like
Reactions: steve333
Hell will freeze first before that happens. I would prefer Apple invest some serious resources in Safari rather than go the Google / Chromium way.

A privacy focused Chromium browser already exists, it is the Brave browser and soon will be joined by the DuckDuckGo browser.
 
For what it’s worth, there’s a difference between WebGL and WebGPU. WebGL is tied to OpenGL ES, which is deprecated on Apple’s platforms in favor of Metal. (And OpenGL doesn’t seem to be long for the world, with the rise of other low latency graphics systems like DirectX 12 and Vulkon.) WebGPU allows for OpenGL and OpenCL style GPU access on Metal, Vulkon, and DirectX 12, and it’s considered the way forward. WebGL is deprecated, to some extent. And, according to the official implementation page hosted by the WebGPU working group on GitHub, no browser has it active by default (it’s hidden behind a flag on Chromium, an about:config pref on Firefox, and the Developer menu on Safari Technology Preview). https://github.com/gpuweb/gpuweb/wiki/Implementation-Status

That’s actually a legitimate issue with standards compliance today and the concept of the living standard. If you invested development time into support for SPDY that couldn’t be re-engineered into support for HTTP2, then you wasted time chasing after a shifting standard. There’s been a lot of pressure within the web standards community to move quickly (to prevent a stagnant period like the IE ascendancy and HTML4’s stagnation), but the downside of that is that the standards bodies have been quick to adopt new standards and browsers have been quick to adopt new de facto standards that are quickly (5 or less years, or so) deprecated in favor of newer, theoretically better approaches to the same issue. Maybe web developers like this state of affairs because it affords them greater job security, but I’d hate to spend the effort getting on a new test framework only to have support for it pulled out from under me less than 5 years later.

There’s also been an issue of web standards by force where Google, in particular, pressures for self-serving standards (some of the progressive web app standards only really make sense in the case of an OS like Chrome OS). Instead of IE’s old de facto standard days, Google tends to force its de facto standards through the standards body. Stuff like WebUSB only makes sense for Chrome OS, and vendor specific stuff like that shouldn’t be allowed to pollute the general body of web standards. Maybe shunt them off into a Web Operating Systems 1.0 standard.

Edit: As an additional note, there are a lot of potential security issues WebGPU (and even WebGL and WebCL) expose, least of which is drive-by crypto mining on users’ GPUs. (The WebGPU team specifically notes that you shouldn’t browse the open web with WebGPU support turned on because of security concerns.) It’s probably a good idea to avoid using it, unless your application 1) absolutely needs to be a web app (or at least makes more sense as a web app than as a local app), 2) absolutely needs the functionality they expose, and 3) can guarantee that it’s running in a tight sandbox and not on the open web (ie a Chrome OS application that’s locally installed instead of being on the web or an Electron application installed to users’ desktops).
Come to think of it, WebGL is itself an example of the pollution of the web standards space. WebGL is based on OpenGL ES, which means that it would run best on platforms with OpenGL ES support. There’s not a one-to-one mapping between OpenGL and OpenGL ES, which means that WebGL wasn’t really suitable for Macs or desktop Linux. What’s more, it was completely unsuitable for Windows. Not to say that you can’t use OpenGL on Windows, but I don’t think most graphics cards in Windows necessarily have great support for OpenGL, let alone Open GL ES.
 
I ****ing hate it

I'd only use it if I need to preserve my battery like crazy ,and assuming the websites I want to use will be loaded properly in safari ,whivh I don't take for granted

chrome has so many more features ,and while it consumes a lot of energy sadly,it just works .

maybe in a few years if chrome gets too bad ,and safari gets better ,I'll think about changing .for now I don't bother anymore and keep it as a battery saver
 
Hell will freeze first before that happens. I would prefer Apple invest some serious resources in Safari rather than go the Google / Chromium way.

A privacy focused Chromium browser already exists, it is the Brave browser and soon will be joined by the DuckDuckGo browser.
the problem isn't just about apple investing in it ,but also web devs that have to make it work for safari engine .

also to me safari isn't just about privacy but also about integration (although I don't care cuz I have neither am iphone nor an ipad )
and energy consumption,processor ,ram,battery . efficiency basically.now whether a chromium based safari would retain said efficiency ,I'm not sure
 
Speaking of Safari, I wonder has Apple thought about making it separate from iOS/iPadOS and allowing regular updates with the App Store app?
I’d doubt it. Apple uses the Safari’s rendering all over the OS. Since a Safari update could potentially break something else in the OS that would make developers unhappy, they’ll likely continue to change them together. Besides, web standards don’t change all that quickly anyway. :) If you look at the differences between Chrome and Safari, very few of the differences affect how a page is viewed using properly formatted html. If developers using Chrome are invoking bugs in Chrome (that render improperly formatted code), then they’re just doing the same thing IE developers did.
 
Until Safari can get uBlock Origin again, I refuse to use it. AdGuard doesn't work on a couple websites, nor does any other ad blocker I've used from the appstore. Quite unfortunate. I use Chrome because of Google Work.
 
“...and there seems to be an angry pocket of men who...” “...We need more voices, not fewer”

Is this Apple rep talking about a web browser (Safari)?
 
“...and there seems to be an angry pocket of men who...” “...We need more voices, not fewer”

Is this Apple rep talking about a web browser (Safari)?
I read that, too, and thought it odd. Does it matter if you're she/he/they/them when you use a web browser? Should it matter if you have an opinion, then, based on your gender? Seems like a pretty harsh thing to add in there when, at the time of this post and following along on twitter, I saw nothing related to 'men' specifically being 'angry' lol. Although I rarely try to digest the random twitter usernames, let alone go further to try and find someone's gender.

Seemed like a very un-Apple'like thing to add in there...
 
  • Like
Reactions: sparky672
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.