If there are a lot of sites that don’t render properly, I’m sure you can provide a link to one that doesn’t.
Too lazy to look at the reported issues in this forum? Easier to switch browser than doing free QA work.
If there are a lot of sites that don’t render properly, I’m sure you can provide a link to one that doesn’t.
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.Too lazy to look at the reported issues in this forum? Easier to switch browser than doing free QA work.
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.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.
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.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.
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.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.
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.Macrumors needs a new news article as the Safari Team is involved in this new effort to improve anything using webkit.
![]()
Apple teams up with Google, Mozilla, Microsoft to improve browser interoperability | AppleInsider
Apple has partnered with Google, Microsoft, and Mozilla on a new endeavor to improve the interoperability and user experience of their web browsers.appleinsider.com
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."
Here's the Interop 2022 information on the webkit site
![]()
Working together on Interop 2022
From the very beginning, the web was always intended to work in any browser, on any computer.webkit.org
![]()
![]()
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-StatusWebGL 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.
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.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).
the problem isn't just about apple investing in it ,but also web devs that have to make it work for safari engine .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.
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.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 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.“...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)?