10 ms·

Safari regularly breaks features that were stable for years: localstorage and indexedDB the most recent ones. So I am not sure how you can talk about "compatibi

by no_way 5y ago

Safari regularly breaks features that were stable for years: localstorage and indexedDB the most recent ones. So I am not sure how you can talk about "compatibility".

masswerk 5y ago
Hm, Safari has done it its own way right from the beginning. (Meaning, Chrome and Safari had never the same implementation.) Edit: As I recall it, Safari was an early adapter of the standard (even before its release), which comes with its own caveats. And it's actually because of not breaking things that there are these Safari idiosyncrasies. (The alternative would have been some kind of rolling prerelease standard, as it had been with Web Sockets. Which means, the API remains somewhat obscure and fragile, even, when it is eventually frozen, and developers have become accustomed to using some wrapper, anyways.) And it isn't so that Chrome wouldn't do it, as well. E.g., a few years ago, Chrome had a major rewrite of the Web Audio framework. With this, any newly created source node would point to a null buffer and any calls to the `play()` method were triggered immediately, referring to this null buffer (instead of automatically pointing to the processed buffer source, as soon as this becomes available, and postponing the call in the meantime). This meant in effect that you could practically play a sound from its decoding callback only (which is somewhat optional and only seldom used). At this point, the Web Audio API had been around for several years and this was breaking about every use of the Web Audio API, there was (including Chrome's previous implementation). Turned out, the standard wasn't exact on this – and it took Chrome several revisions to fix this issue (in the meantime, you could work around this issue by user-agent sniffing only). The standard was eventually updated to define the specific behavior. (This is probably also why most developers ignore the Web Audio API for the most and use some wrapper instead. Which is much like using jquery to work around IE idiosyncrasies.) Also, what would it have cost Chrome to implement KeyboardEvent.keyIdentifier to provide a somewhat compatible API?
- jahewson 5y ago
  As a user of Web Audio I can tell you that it’s broken in the latest Safari. As in, we cannot play a simple sound. Our users are not happy about it.
  - masswerk 5y ago
    It requires a user initiated event to unmute the AudioContext first. (This is a fallout of the constant struggle between advertising and browsers, compare the restrictions for auto-play videos. Regarding the latter, if you're not white-listed by Google, you're out of luck on Chrome and your entire site is broken. Safari's restrictions on audible sound are actually transparent in comparison.)
  - mikestew 5y ago
    It's not broken. Maybe your code is broken, I dunno, as I don't have it in front of me. But Web Audio most certainly works "in the latest Safari".
  - marcellus23 5y ago
    I'm running latest Safari and I can definitely play sounds on websites. Is Safari broken, or just your code?

by no_way 5y ago

Safari regularly breaks features that were stable for years: localstorage and indexedDB the most recent ones. So I am not sure how you can talk about "compatibility".

masswerk 5y ago

Hm, Safari has done it its own way right from the beginning. (Meaning, Chrome and Safari had never the same implementation.) Edit: As I recall it, Safari was an early adapter of the standard (even before its release), which comes with its own caveats. And it's actually because of not breaking things that there are these Safari idiosyncrasies. (The alternative would have been some kind of rolling prerelease standard, as it had been with Web Sockets. Which means, the API remains somewhat obscure and fragile, even, when it is eventually frozen, and developers have become accustomed to using some wrapper, anyways.) And it isn't so that Chrome wouldn't do it, as well. E.g., a few years ago, Chrome had a major rewrite of the Web Audio framework. With this, any newly created source node would point to a null buffer and any calls to the `play()` method were triggered immediately, referring to this null buffer (instead of automatically pointing to the processed buffer source, as soon as this becomes available, and postponing the call in the meantime). This meant in effect that you could practically play a sound from its decoding callback only (which is somewhat optional and only seldom used). At this point, the Web Audio API had been around for several years and this was breaking about every use of the Web Audio API, there was (including Chrome's previous implementation). Turned out, the standard wasn't exact on this – and it took Chrome several revisions to fix this issue (in the meantime, you could work around this issue by user-agent sniffing only). The standard was eventually updated to define the specific behavior. (This is probably also why most developers ignore the Web Audio API for the most and use some wrapper instead. Which is much like using jquery to work around IE idiosyncrasies.) Also, what would it have cost Chrome to implement KeyboardEvent.keyIdentifier to provide a somewhat compatible API?

jahewson 5y ago
As a user of Web Audio I can tell you that it’s broken in the latest Safari. As in, we cannot play a simple sound. Our users are not happy about it.
- masswerk 5y ago
  It requires a user initiated event to unmute the AudioContext first. (This is a fallout of the constant struggle between advertising and browsers, compare the restrictions for auto-play videos. Regarding the latter, if you're not white-listed by Google, you're out of luck on Chrome and your entire site is broken. Safari's restrictions on audible sound are actually transparent in comparison.)
- mikestew 5y ago
  It's not broken. Maybe your code is broken, I dunno, as I don't have it in front of me. But Web Audio most certainly works "in the latest Safari".
- marcellus23 5y ago
  I'm running latest Safari and I can definitely play sounds on websites. Is Safari broken, or just your code?