This website doesn't currently work in Safari
Closed this issue · 11 comments
When I navigate to http://wiki.c2.com in safari, I only get a loading spinner. Checking the console, it complains about lacking the fetch variable. http://caniuse.com/#search=fetch shows that it's not available on Safari (current or mobile) or Opera Mini.
Since a decent number of developers work from Macs (like myself), having a polyfill for it would be nice. Looking for polyfills, I found https://github.com/github/fetch/blob/master/fetch.js.
We're testing with chrome and firefox on mac. As a forward looking project we get little benefit from supporting older browsers.
On Oct 29, 2016, at 5:02 PM, yumaikas notifications@github.com wrote:
When I navigate to http://wiki.c2.com in safari, I only get a loading spinner. Checking the console, it complains about lacking the fetch variable. http://caniuse.com/#search=fetch shows that it's not available on Safari (current or mobile) or Opera Mini.
Since a decent number of developers work from Macs (like myself), having a polyfill for it would be nice. Looking for polyfills, I found https://github.com/github/fetch/blob/master/fetch.js.
�
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
This is the current version (9.x-10.x) of Safari, which means that the site is broken on the vast majority of Apple hardware, for the browser that makes the best use of the battery on Apple laptops. This is currently the biggest reason to use Safari on Mac. I'm willing to make a PR to bring in the polyfill, but we aren't talking super legacy stuff here, but what the current stable tech on Mac is. Not everyone can be on the bleeding edge of everything.
I do wish Apple would keep up with Web standards a bit more proactively (this isn't the first time a site has been broken in Safari). I just think that it'd be a shame for c2 wiki to be completely unusable on Safari (which is where it currently is).
Ok, we will put support for apple safari on our priority list. But don't expect it to be too high. Wiki was founded when most browsers didn't have textarea but they caught up. I'm sure apple has some logic for dragging their feet but I don't work for them. If you work for them, tell them to get going. Try chrome or firefox in the interim.
Total rando here, butting in where I'm probably not welcome.
The fetch polyfill is a drop-in. It takes less than 10 seconds to make fetch work in all modern browsers. Almost 45% of web traffic in the US can't use this website at all. It's about as high on the bang-for-your-buck scale as you'll get.
Just my 2% of a dollar.
@joshbroton, I couldn't see where the suggested polyfill would work with Promise.all(). My goal was to overlap the two potentially slow fetches and all() appeared to be the way to do it.
It looks like the fetch polyfill relies on an existing promise implementation (for things like all()), which has availability across 75% of most common browsers: http://caniuse.com/#feat=promises
As far as promise polyfills go, I found https://github.com/stefanpenner/es6-promise, which has
a download as a file that can be dropped in.
Just dropping this here for if/when you decide to give this a look over.
That's the ticket! I used that combination on the last four big fetch-using projects that I've built. It works like a charm!
I was premature closing this issue. Sorry. I will restrict my focus here on benefiting from web standards where they exist but will not intentionally take sides in a standardization debate in progress. I was unaware of opposition to fetch when I chose to use it.
I am currently pursuing three different client-side approaches to distributing this material. Two use code generators: coffeescript and react. I would like to maintain this version as a single, small, hand-written program similar to the original server-side perl. The perl implementation has run effectively for 20 years because it took no dependencies. (The first version used the built-in DBM library which was a disaster. Replacing that with flat files was a big win.)
I'm not likely to incorporate polyfills. I am especially against complex build infrastructure which won't last for 20 more years. I understand why this expediency is expected of work-for-hire. I feel I am working with a different charter. If there is anything like a vendor consensus for ajax in the web today it is xhr. I will seek to fetch two files hand-coding against this abstraction.
Hi @WardCunningham,
Although it appears true that Safari doesn't support Fetch currently, there's no real standards debate here in progress, or opposition from Safari; it's just that Safari is still working to implement. You can see they support Fetch in their Tech Preview builds, and they've been very active in the standards community collaborating on making Fetch and related features better. I also think it might be a bit uncharitable to characterize them as "dragging their feet"; they're just resource-constrained, like all browser teams, and are still working through the final issues in their Fetch implementation before they can flip the flag and turn it on in stable builds.
28f1a05 now supports safari with hand-coded xhr.
I followed the same functional decomposition as the original fetch code but with callbacks for signaling. I'll save the fetch code here for future reference.
function fetchNames () {
return fetch('names.txt')
.then(function(response) { return response.text() })
.catch(trouble)
}
function fetchPage () {
title = (location.search.match(/\w+/)||["WelcomeVisitors"])[0]
var database = 'http://c2.com/wiki/remodel/pages/'
return fetch(database + title)
.then(function(response) { return response.json() })
.catch(trouble)
}
function init() {
Promise.all([fetchNames(), fetchPage()])
.then(function (data) {
names = data[0].split(/\r?\n/)
show(data[1])
})
}