2 ms·

Short version of a long story! A few years ago Google implemented autoplay blocking in Chrome. It was designed to fix problems like this, but was riddled with i

Short version of a long story! A few years ago Google implemented autoplay blocking in Chrome. It was designed to fix problems like this, but was riddled with issues. I wrote about it at https://danshumway.com/blog/chrome-autoplay/ https://danshumway.com/blog/chrome-autoplay/. The spec evolved a little bit since then, so not everything in that post is up to date, but most of the core problems still remain (or did the last time I checked). Firefox was forced to follow suit, and to their credit their spec was a lot more sensible, but it was really only papering over the problems in the Chrome spec. It wasn't at a fundamental level thinking about video/audio differently than Chrome was, it was just trying to do the same thing minus the egregiously bad decisions. I feel like a lot of the problems with hijacked interactions on the web can be traced back to spec histories like this. A good implementation of video/audio blocking: - wouldn't reveal to the page that audio was blocked, it would either silently mute the audio or refuse to render the video without reporting an error. - wouldn't have exceptions based around trying to interpret user intent or (in Chrome's case) exceptions based on how you navigated to the page. - wouldn't try to distinguish between things like GIFs, animated backgrounds, and videos (they're all moving pictures that use data and distract motion-sensitive users, you don't need to treat them differently) My (subjective) opinion is that video autoplaying never really got better because we never really tackled the problem correctly from the start, and since then we've just been continuing to apply band-aides on top of a fundamentally broken strategy. > am I the only one? Depending on how much you hate this and how much effort you're willing to put into getting rid of it, disabling 3rd-party Javascript will fix the problem on most news sites. Nearly all of them that I run into load the Javascript to run the player from a separate script being served from a separate subdomain or CDN. It's usually possible (even for news sites that require Javascript) to block that script in specific, or load just enough Javascript to get the page rendering and nothing else.

NoodleIncident 6y ago
> wouldn't try to distinguish between things like GIFs, animated backgrounds, and videos (they're all moving pictures that use data and distract motion-sensitive users, you don't need to treat them differently) This would cause 95% of users to correctly say that your browser is "broken", regardless of the opinions of motion-sensitive users on tiny data connections. Having a nuclear option for just these people is fine, but you do need to distinguish between the two types of video for everyone else.
- danShumway 6y ago
  > Having a nuclear option for just these people is fine I think that would be fine, I'm certainly not against sensible defaults. But I don't think any browser currently has a good implementation of that nuclear option The distinction between video types shouldn't be something that's baked into the core design of the feature itself. As it stands, I have no idea how I'd even start to implement a good nuclear option on top of the current design of autoplay blocking. There are so many weird rules about what is and isn't allowed to work, and the end result is that the system is trivial to bypass. One of the criticisms I had when the system launched was that it's really not hard to make an autoplaying video even with these restrictions[0] -- clicking, highlighting, or pressing any keyboard key counts as a user action. Or if you're navigating within a domain, then your video is special and allowed to autoplay. The distinction between "this is probably an animated background image" and "this is probably a video banner" is fundamentally baked into the feature itself in a way that users can't customize or disable, and where its difficult for even the browser-makers themselves to expand on the feature of change it as the ecosystem evolves. Even the distinction between autoplay on page load and autoplay in general is a bad one to have so hard-coded into the design. Youtube is an SPA, so even though Firefox properly blocks autoplays while you're moving within a domain, that doesn't work on Youtube, because no actual navigation happens when you click a link in Youtube, so Firefox thinks you've already given the page permission to auto-start the video. That's a really inconsistent, bad user experience for nontechnical users who have no idea what an SPA is. [0]: See https://danshumway.com/blog/chrome-autoplay/demo/ https://danshumway.com/blog/chrome-autoplay/demo/ for a really simple implementation. If I'm building a news site and I want autoplaying ads, I'm pretty certain at some point while reading you're going to highlight some of the text on the page.

NoodleIncident 6y ago

> wouldn't try to distinguish between things like GIFs, animated backgrounds, and videos (they're all moving pictures that use data and distract motion-sensitive users, you don't need to treat them differently) This would cause 95% of users to correctly say that your browser is "broken", regardless of the opinions of motion-sensitive users on tiny data connections. Having a nuclear option for just these people is fine, but you do need to distinguish between the two types of video for everyone else.

danShumway 6y ago
> Having a nuclear option for just these people is fine I think that would be fine, I'm certainly not against sensible defaults. But I don't think any browser currently has a good implementation of that nuclear option The distinction between video types shouldn't be something that's baked into the core design of the feature itself. As it stands, I have no idea how I'd even start to implement a good nuclear option on top of the current design of autoplay blocking. There are so many weird rules about what is and isn't allowed to work, and the end result is that the system is trivial to bypass. One of the criticisms I had when the system launched was that it's really not hard to make an autoplaying video even with these restrictions[0] -- clicking, highlighting, or pressing any keyboard key counts as a user action. Or if you're navigating within a domain, then your video is special and allowed to autoplay. The distinction between "this is probably an animated background image" and "this is probably a video banner" is fundamentally baked into the feature itself in a way that users can't customize or disable, and where its difficult for even the browser-makers themselves to expand on the feature of change it as the ecosystem evolves. Even the distinction between autoplay on page load and autoplay in general is a bad one to have so hard-coded into the design. Youtube is an SPA, so even though Firefox properly blocks autoplays while you're moving within a domain, that doesn't work on Youtube, because no actual navigation happens when you click a link in Youtube, so Firefox thinks you've already given the page permission to auto-start the video. That's a really inconsistent, bad user experience for nontechnical users who have no idea what an SPA is. [0]: See https://danshumway.com/blog/chrome-autoplay/demo/ https://danshumway.com/blog/chrome-autoplay/demo/ for a really simple implementation. If I'm building a news site and I want autoplaying ads, I'm pretty certain at some point while reading you're going to highlight some of the text on the page.