4 ms·

Does this follow the relevant standards, which I presume exist? Or is Google making a breaking change and requiring the web change to accommodate?

gsnedders 8y ago
> Does this follow the relevant standards, which I presume exist? Yes. For <video> and <audio>, the spec only says the UA "may" (RFC 2119) follow the autoplay steps, and the play() method only does anything "if the user agent and the system allow media playback in the current context". For WebAudio, the spec says, "An AudioContext is said to be allowed to start if the user agent and the system allow audio output in the current context". So the UA is always allowed to decide whether or not to start playing media.
- sp332 8y ago
  ^ Could someone who downvoted this comment explain why? Is it wrong or what?
nfriedly 8y ago
This is part of the standard. It basically leaves the choice up to the browser: > An AudioContext is said to be allowed to start if the user agent and the system allow audio output in the current context. In other words, if the AudioContext control thread state is allowed to transition from suspended to running. https://webaudio.github.io/web-audio-api/#AudioContext https://webaudio.github.io/web-audio-api/#AudioContext Also, I think Apple did it first, (on mobile Safari) and then Google on mobile Chrome, and now on desktop Chrome.
kakarot 8y ago
WebAudio is caught in standards limbo. I learned to just stay away from it a while back until it's fully standardized. What had happened was, Mozilla and Google were working on making their implementations compliant, when Google did the thing they love doing that really makes Chrome no better than IE: implemented their own, incomplete version of WebAudio and sent it out the gate. Mozilla then felt pressure to follow suit. Then we decided the standards needed to be improved again. So now both browsers have a slow, half-assed, broken implementation of WebAudio that isn't good for too much and that neither of them seem intent on fixing until the standards clear up.
fenomas 8y ago
I'm no expert but I believe it follows standards. Quoting the spec: > Note: For example, a user agent could require that an AudioContext control thread state change to running is triggered by user activation https://www.w3.org/TR/webaudio/#allowed-to-start https://www.w3.org/TR/webaudio/#allowed-to-start That's essentially what the Chrome policy does - it changes when the AudioContext moves from the "suspended" state to "running".
- gsnedders 8y ago
  That's a non-normative note, the normative statement that allows the behaviour is the paragraph before that.
jamesgeck0 8y ago
It does follow standards, and it does break a lot of old browser games, some of which aren't maintained or can't be easily updated.

gsnedders 8y ago

> Does this follow the relevant standards, which I presume exist? Yes. For <video> and <audio>, the spec only says the UA "may" (RFC 2119) follow the autoplay steps, and the play() method only does anything "if the user agent and the system allow media playback in the current context". For WebAudio, the spec says, "An AudioContext is said to be allowed to start if the user agent and the system allow audio output in the current context". So the UA is always allowed to decide whether or not to start playing media.

sp332 8y ago
^ Could someone who downvoted this comment explain why? Is it wrong or what?

nfriedly 8y ago

This is part of the standard. It basically leaves the choice up to the browser: > An AudioContext is said to be allowed to start if the user agent and the system allow audio output in the current context. In other words, if the AudioContext control thread state is allowed to transition from suspended to running. https://webaudio.github.io/web-audio-api/#AudioContext https://webaudio.github.io/web-audio-api/#AudioContext Also, I think Apple did it first, (on mobile Safari) and then Google on mobile Chrome, and now on desktop Chrome.

kakarot 8y ago

WebAudio is caught in standards limbo. I learned to just stay away from it a while back until it's fully standardized. What had happened was, Mozilla and Google were working on making their implementations compliant, when Google did the thing they love doing that really makes Chrome no better than IE: implemented their own, incomplete version of WebAudio and sent it out the gate. Mozilla then felt pressure to follow suit. Then we decided the standards needed to be improved again. So now both browsers have a slow, half-assed, broken implementation of WebAudio that isn't good for too much and that neither of them seem intent on fixing until the standards clear up.

fenomas 8y ago

I'm no expert but I believe it follows standards. Quoting the spec: > Note: For example, a user agent could require that an AudioContext control thread state change to running is triggered by user activation https://www.w3.org/TR/webaudio/#allowed-to-start https://www.w3.org/TR/webaudio/#allowed-to-start That's essentially what the Chrome policy does - it changes when the AudioContext moves from the "suspended" state to "running".

gsnedders 8y ago
That's a non-normative note, the normative statement that allows the behaviour is the paragraph before that.

jamesgeck0 8y ago

It does follow standards, and it does break a lot of old browser games, some of which aren't maintained or can't be easily updated.