5 ms·

I live a quiet life and want my browser to be quiet too. I don’t fully understand the API changes behind this decision but from what I have read this is a huge

by xfitm3 8y ago

I live a quiet life and want my browser to be quiet too. I don’t fully understand the API changes behind this decision but from what I have read this is a huge win. The real problem is the unethical use of APIs to increase advertisement related KPIs.

sp332 8y ago
Not that many people are really advocating for autoplay. They just want a way to enable audio on specific sites. The Chrome changes take control away from the user.
fenomas 8y ago
You're saying you like the intent of the policy - that's fair enough. I'm saying that the implementation didn't match the intent - Chrome broke WebAudio sites regardless of whether they followed the intended policy. That's not a big win for anyone, it just breaks content to no benefit.
ksk 8y ago
The simplest solution is to not visit sites that don't respect your point of view. Reward sites who align with your interests and views.
tokyodude 8y ago
You might be right that someday there would be unethical uses of the WebAudio API but AFAICT there are almost none today. Instead there are lots of sites that abuse the video tag playing video when I want none. A bunch of popular news sites do this. So, maybe this was a huge win in the future but it was a huge lose now. It affected ~0 advertisers and instead affected 1000s of interesting and experimental sites.
brian-armstrong 8y ago
You're making a different argument than the GP. Mobile Safari already has this requirement and it works in a different way. The problem is that the Chrome team did it in a completely different way that broke everyone's expectations. It also didn't make any sense. Why would you require the dev to unpause the Context themselves? Why not just unpause it automatically once the user has interacted in the right way? And now that Chrome has moved, what if Edge and Firefox create their own 3rd and 4th standards. I have a library that was broken by this. It was an easy fix, but it was still headscratching that I needed to do anything. Like most libs, I was already complying with the mobile Safari way of doing things.

by xfitm3 8y ago

sp332 8y ago

Not that many people are really advocating for autoplay. They just want a way to enable audio on specific sites. The Chrome changes take control away from the user.

fenomas 8y ago

You're saying you like the intent of the policy - that's fair enough. I'm saying that the implementation didn't match the intent - Chrome broke WebAudio sites regardless of whether they followed the intended policy. That's not a big win for anyone, it just breaks content to no benefit.

ksk 8y ago

The simplest solution is to not visit sites that don't respect your point of view. Reward sites who align with your interests and views.

tokyodude 8y ago

You might be right that someday there would be unethical uses of the WebAudio API but AFAICT there are almost none today. Instead there are lots of sites that abuse the video tag playing video when I want none. A bunch of popular news sites do this. So, maybe this was a huge win in the future but it was a huge lose now. It affected ~0 advertisers and instead affected 1000s of interesting and experimental sites.

brian-armstrong 8y ago

You're making a different argument than the GP. Mobile Safari already has this requirement and it works in a different way. The problem is that the Chrome team did it in a completely different way that broke everyone's expectations. It also didn't make any sense. Why would you require the dev to unpause the Context themselves? Why not just unpause it automatically once the user has interacted in the right way? And now that Chrome has moved, what if Edge and Firefox create their own 3rd and 4th standards. I have a library that was broken by this. It was an easy fix, but it was still headscratching that I needed to do anything. Like most libs, I was already complying with the mobile Safari way of doing things.