There need to be more strict settings for autoplay, not only for video and audio, but for huge GIF files too. I'd put them under "energy saving" settings, as reduced network activity would benefit for server too, not to mention all CPU cycles saved for not decoding all media on client side. Autoplay activation triggers should be reviewed as well, as some sites will happily start autoplaying all media after scrolling down using main scrollbar. That's probably only me, but I still consider scrollbar a part of browsers chrome, not part of website. So interacting with it should not give any hints to website, at least where media autoplay is concerned.
The worst thing is those websites that have some type of 2160p type of video autoplay as a background image, making it unbrowsable on cheaper hardware devices.
But this is more a rant for modern webdev practices I'm not sure much can be done to circumvent it from a browser perspective.
Back when Opera was a worthy browser, around 2000, it had various bandwidth-saving and CPU-saving controls. In particular, it had buttons to prevent loading of large images, and IIRC for gif autoplay.
Pretty sure this is part of uBlocks standard features.
Honestly it's getting a bit too noticeable how a full-featured adblocker is converging on just a way to let the user take back control over the user agent.
I wonder why nobody introduced a "Accept-Max-Size" request header?
Chrome is toying with custom accept header[1] types but they're used by servers to request information from clients, which is completely missing the point in my opinion.
I wish gif’s adhered to prefers-reduced-motion and preferably only played on interaction. I use Toggle Animated Gifs [0], but it’s a global on/off switch, requires a reload, and doesn’t show a hint that something could be animated.
Ublock origin has this feature where it blocks large media files automatically (you have to click to load them). I use it for a long time and never had problems because of it.
I don't need any strict settings for autoplay. I don't need autoplay.
Maybe there could be like a 2Mb cap on each page load that you'd manually had to extend the quota on. Most sites that need more are accidental visits anyway. That should work even if the site is user hostile.
How would that cap work? Would the browser be expected to calculate the size of all elements by querying them all before loading anything? Would the browser just start downloading content counting bits as it goes, and then just stop when it reached 2Mb? What if the page was laid out in such a way that the JS includes were >2Mb?
Just a second of though about the comment made would show so many issues with the idea, that maybe the idea isn't really a good one. At the least it would provide pause that maybe some sort of refinement is required to be taken seriously by anyone else.
I was thinking like, don't make any more request if the limit is transgressed. So the limit could be surpassed by the last request.
Otherwise I guess the limit could be in the tcp layer too.
And the limit would not care about breaking sites. So I guess it would only be aimed at technical users on mobile where bytes count. Unless it is easy to "continue" without serverside state breaking.
What would happen if you yanked the ethernet cord after 2Mb transferred? Same thing. You can't precalculate the size since resources are added dynamically (and you can't trust HEAD anyway).
it's rare for the html file and the associated css is bigger than 2MB (much epub books is lighter than that if you reduce image size). The culprit are often media (fonts included), JS files, and files loaded dynamically. I'd say get the HTML and CSS files first, then JS and everything else and stops after the 2MB threshold. A lot of currently running JS code are unnecessary and I say this as a React developer.
so many websites don't actually have full HTML. Instead, its just JS that dynamically create elements after fully being downloaded. Not acknowledging this just shows how much of a not good/realistic/practical idea this is. Pie in the sky idealistic concepts are fun sitting in a pub having a few pints or while sitting in the circle, but they are not productive suggestions in making things better.
Making things better is forcing website owners to go back to server-side rendered applications. I just blocked the JS files on my self-hosted instance of Gitea to load, and the resulting total size is close to 900kb, with my profile picture file at 250kb. It is still usable. With JS files, the whole thing is 2.2mb and took two seconds to render (0.7 seconds for file transfers). Caching was disabled. Most websites shouldn't be SPA. And the actual instantaneous navigation argument is often negated by slow data loading. Instead of the browser showing a loading bar, it's the application doing it.
As you can't control other people's choices, you can only control your environment. Which often means Firefox+Ublock/NoScript. I use Safari, but only visit a handful of these kinds of sites and never for long, often immediately closing tabs that show popups and annoying animations. And I have a pihole on my network.
Your declaration of websites not needing to be SPA may or may not be accurate. However, there are so many sites that are made from template providers like Wix/SquareSpace/Shopify/whatEvs that allow people with 0 knowledge of how a website is made. These sites will not render without JS.
These are companies that have allowed so many people to have a website that essentially is a SPA because that's an easy way for them to deploy template based sites. These are much easier to maintain than WordPress sites. Yes, I agree that most of these sites are simply static sites, and I think it would be amazing if these template JS library sites would allow you to render it flat static site once you hit publish or the equivalent. However, they would probably balk at the notion of not protecting their IP with obfuscated code and delivering readable HTML/CSS. I seriously doubt it takes 2MB of JS to operate these sites, and I'm guessing probably 90% of that code isn't used but is just bundled so the same thing is used everywhere.
However, to prove your point, there are many occasions where I've taken as a weekend project to find a template from Wix or similar that I like, and then recreate it in HTML/CSS by hand. It very much is a smaller site. But that's not something anyone here is disputing. The dispute is that you're wanting a fantasy world, and that's not the one we live in.
Just as the article [0] have described it, the web is already split. You can either choose Times Square or the scenic retreat, the consumer magazine or a nice book. I choose to minimize my time on the "normal" web which breaks if I block ads and tracking scripts. And instead spend it here and in my RSS reader.
If you want all the javascript, don't count the javascript against the quota.
If you don't want videos that you're never going to play deliberately, set the video quota to zero.
Most autoplays seems user hostile. And it is futile to execute hostile code and try to make it behave. (Kudos for UBlock Origin etc for trying anyway, though!)
But at least there should be an easy way to make a website not have access to your speakers unless you opt in. 99% of the times, it's ads anyway, so the default should be to block sound. But that does not solve the bandwidth waste problem.
Fundamentally, the problem is Javascript. It makes it really hard for the user to be in control.
This is a further issue for those using e-ink devices (tablets, e-book readers, monitors), where rapid animation at higher quality settings is exceedingly disruptive --- stuttering, screen-flashing, and the like. (It is possible to display animations, if desired, at reasonable refresh rates using lower-quality display settings, e-ink offers a trade-off between text quality (resolution, ghosting) and refresh rates. But as if there needed to be additional arguments to put a hard stop on highly-distracting design elements, this really stands out.)
I've also found it ... interesting ... to note that a single Web page often has the memory footprint of an entire book (a few MB for just plain text, though that can balloon upwards with complex typesetting and graphics), and that even a browser optimised for e-ink (Einkbro) has roughly 10x the power consumption of the stock ebook reader (Neoreader) on my Onyx BOOX tablet (labeled as an e-book reader, but in fact an e-ink based Android tablet).
I can read books for days on a single battery charge. I can browse the Web for ... a few hours.
While the web allows for a lot of creative expressions, I think we should have companion protocols for alternate consumptions methods, something like Gemini for every page. An e-ink reader is good for focused reading, but bad for interactive or animated content. Just like gwern.net allows to add `.page` to every link and get the raw source, you could add `.gemini` to wikipedia pages and get a much simpler document that you can read on e-ink reader or a cli device (should be good for accessibility too).
I'd really like to see something like this and have thought that an online publishing engine which would produce HTML, ePub, PDF, or other output formats or endpoints on demand might be useful.
There are sites already which provide some form of this, notably sites using MediaWiki (which notably powers Wikipedia and Wikisource) offer multiple download options, though I don't think it's quite as flexible as I'd prefer.
Client support would be the other factor, with current Web browsers not being particularly multi-format. Though to be fair, Firefox, Safari, and Chrome all now natively support PDF documents.
I suspect that a render-to-ePub would be a much better alternative to standard HTML for mobile devices. ePub is inherently fluid, and tends to offer a subset of full HTML capabilities. (ePub is of course an archive of HTML, stylesheet, and other elements, though usually it's more strongly textually oriented than the modern Web is.)
For sufficiently large tablets, PDFs are actually a quite good document format.
Update: as I noted in another comment, both Wikipedia and Wikisource of course run MediaWiki as their wiki engine. Not sure if the HTML/PDF capability is baked in there or not.
You are right, but it’s at least one step in the right direction. Browsers are so timid when it comes to giving users control, I’ll take anything.
I don’t get this web developer attitude of just ignoring the user’s preference and working around it. The user should be in control of what the browser is doing, not the web developer. I really want to love JavaScript but it’s power to override user preferences is inexcusable.
Safari desktop has recently made toggling JavaScript a huge pain in the ass. Before, it was just in the menu: Develop -> Disable JavaScript. With the most recent Safari, you have to go into Settings, then Security tab, then uncheck Enable JavaScript.
Horrible and totally unnecessary UI change, Apple. You could have easily kept the menu item. This is a frequently used action, it shouldn't be buried in Settings!!
honestly, I still feel like that is a win for users. pop-ups that are modals on a site is not anywhere close to open application windows, especially the pop-unders. to me, opening another application window on my system is much more abhorrent than a site deciding it wants my attention somewhere else on its site.
I still find it distasteful that Chrome's autoplay policy was "we allowlist a 'fair' list of popular websites that happens to include all of our big domains", when the UX for that isn't meaningfully better than the way it works in Firefox. I can't imagine it actually had much of a positive impact on Google's metrics either, so it felt like a huge waste of effort + additional complexity for nothing.
I wonder if the Firefox team ever considered taking the same approach to make Youtube "just work". Clicking allow the first time and never thinking about it again is pretty easy.
Firefox's default "allow autoplay after interaction" policy doesn't help much in the case of SPAs. Go to a site like ESPN and autoplay will be blocked on the first "page" you visit, but navigating to any subsequent "pages" ends up enabling autoplay since link clicks are intercepted and Javascripted away.
What I really want browsers to adopt is an SPA breaking policy, where click handlers for <a> elements are ignored for non-whitelisted sites.
None of our SPAs use <a> elements for clickable navigation. In fact, most of them attach a click listener to the root element, then let the individual clicks bubble up to there. We use data parameters on the individual elements, and if the click handler sees one of those, then it activates the history state/navigation.
In terms of autoplay, a trick we have to play for iOS is, when you click on something we play a 0.25 second silent MP3 through the audio element. Once that's done, it's "active" and we can use it to play audio.
It's a radio "boombox" type application, so this feature is expected by our users to keep audio playing when they navigate to different features within the player.
> None of our SPAs use <a> elements for clickable navigation. In fact, most of them attach a click listener to the root element, then let the individual clicks bubble up to there. We use data parameters on the individual elements, and if the click handler sees one of those, then it activates the history state/navigation.
This breaks a lot of navigation features though, right? For example, middle click or control click to open in a new tab, hovering to see where the link will take you, right clicking to save, copy, or share a link, etc.
Why not just have them be anchor elements with hrefs that refer to the URL that you'll be using the history state with? You can still listen to the click events and perform the required history updates and navigation when that occurs, but if the user interacts with that link outside of just clicking it, it'll behave as they expect. Depending on how your navigation works, this could well be less work overall - this has certainly been my experience with similar projects.
That makes sense for an audio-player application -- something like Spotify where the user expects playback to continue when navigating pages. Even so, I rely on the fact that Spotify links are actual links, so that I can open multiple tabs when I need to, for example when putting together a complicated playlist. Have you considered keeping <a> links as a fallback to support this sort of use-case?
They could get rid of links, but that would break search engine indexing. This wouldn't be an issue for legitimate SPAs like Gmail, but would be disastrous for content-based sites. More likely is that they'd keep <a> elements but hide them from the user.
Either way, my proposal would make sites that eliminated or hid <a> elements stop working by default, which would disincentivize hostile UX practices.
It helps if you're the kind of person who only ever opens links in new tabs. Firefox is way better for me than Chrome when I do that. Eg if I'm browsing Youtube's front page and I middle-click three videos in a row, I don't want all of them to start playing at the same time.
Not sure if I enabled some Chrome setting or what but when I middle click on a Youtube thumbnail the video won't start playing until I focus on that tab.
Because most SPAs that I interact with (like ESPN) have no business being SPAs (in the sense of hijacking navigation). The main motivation behind constructing them that way seems to be to circumvent UX safeguards.
The key to what I'm envisioning is that it wouldn't break a site like ESPN entirely -- it would just break the SPA behavior by making links behave like links. The end result is that the site would be more usable, not less.
For sites where SPA behavior is necessary (like Spotify), opting in could be done with a one-time browser prompt, like how location access and DRM playback are handled.
This seems like a more realistic solution than just avoiding these sites altogether, for the same reason that people use ad blockers instead of just shunning sites with ads.
How many web apps from 15 years ago still work? Flash, Java applets, browser specific hacks, fingerprinting, cross-origin shenanigans... all locked down or eliminated. The internet evolves by breaking APIs.
Would you stop using GitHub as well. They recently move to a SPA models and I think search and readme links were broken for a few days because of history hijacking.
I really enjoy this as a feature. There are many times that I don't need a video full frame, but don't want to see the rest of the website page either (I'm looking at you YouTube). I can just pop the video out, and even shrink its size, and then go back to whatever else I need to be looking at.
Sadly, there are so many videos out there that do not need to be videos, yet that's how they are presented for sometimes rational reasons on the "creator's" part.
I managed to somehow disable the button that appears on the video without totally disabling the feature. I find it a lot more ergonomic to hit ctrl+shift+] to toggle it.
I pretty much only use it for videos yt-dlp + mpv can't open though.
I disliked it because when I click on another link I expect to see the new webpage and nothing else. Instead, I have the video continuing playing on the side so I have to manually close it aswell. That combined with the video player taking up unnecessary space for me, it's even worse on the phone, some picture-in-picture players eat up 1/4 of the screen.
That only affects the controls of the PIP mode, the question was how to completely disable PIP mode. A sibling comment posted a about:config setting to do this.
I don't know if it's still the case, but a while back Firefox would allow muted looping videos to auto play, basically like an animated gif. However, if the video had an audio track (even muted) it would keep the computer from sleeping.
Some of adafruits documentation pages had exactly this combination, so leaving a single page of documentation open would keep my computer from automatically sleeping.
I interpreted the comments on that bug to mean that the Adafruit site has an unmuted video that happens to have a silent audio track, which isn’t strictly a muted autoplay issue. But maybe I’m wrong.
Yeah, I think there was some confusion about which video on the page was causing the issue, but the test cases I created are much simpler - just one video per page.
It would be useful if Firefox recorded which configs the user changed. Imagine if you could view a chronological, tabular list of all configs that you changed. Name, default value, changed value, date.
Firefox has all of this except the date. `about:config` lists all config values, values in bold do not match their default or do not exist by default, values can be reverted with one click, and there's a checkbox to filter out unmodified items.
But does that include the personalized settings for a specific site?
I mean Tools menu -> Page Info -> Permissions
An example: the gong doesn't sounds when a game starts in lichess if you have autoplay disabled for sound. You need to allow that for the site. There are other configurations there like accepting cookies, etc.
about:preferences#privacy, scroll down a bit, it's under "Permissions". You can also adjust it when on the site, using the icon at the left of the URL bar.
Firefox has fine-grained site permissions, which probably cover this. The UI is pretty obscure, though, and not discoverable, which may be why this option isn't considered in the article.
> I've been buying digital music from one of the reasonably good online sources of it (the one that recently got acquired, again, making people nervous about its longer term future).
You'd need to set up containers, associate them with specific websites (not sure if this is possible or I'm confusing FFMACs with Chrome's own container feature), and then of course tweak your Firefox configuration as you prefer it for the site(s) associated with each container/account.
I wish it would all be disabled. On iOS it is absolute hell to load any page due to it jumping around, and then you scroll and some video starts playing. Do you want me to read the page? Or get distracted? Either PIP with a too small x, or inline, making me think it's part of the story, but it's just another story about Mary eating 36 pastries and winning the eating contest.
For the longest time Ars Technica did this too, with the same video over and over. I can't imagine the bandwidth wasted there.
I honestly at this point, don't feel the need to have anything auto play, if I want video, or audio, I'm well on able to click a button myself.
Auto play = auto advertisement in most cases I encounter it. I can't not see why at this day in age we are prioritizing anyone but the user making the choice of when to play something.
> As discussed in Mozilla's wiki page on blocking media autoplay, the default setting for this preference allows autoplay once you've interacted with that tab,
I despise this idea with a burning passion. It means that the instant you scroll down the page, or bring up a menu, or "interact" for some definition of the word, BOOM! some obnoxious video starts playing.
At the time, there was a lot of noise about the fact that autoplay settings were breaking parts of the web, and I do think that was a problem with Chrome's setup that never really got addressed. My article focused only on Chrome's changes.
Firefox's approach was (imo) better -- it didn't have as much of the weird AI-driven "figure out which domains users interact with" nonsense -- but Firefox's approach was still very clearly influenced by Chrome's, and I would argue that Chrome's approach was incorrect.
At the time, there were two concerns, and Chrome's approach was only intended to handle one of them:
1. Autoplay videos use a lot of bandwidth
2. Autoplay videos are disruptive (specifically, they make noise)
Chrome was worried about #2. They argued (and I agree with this) that these are two separate concerns that need to be tackled separately. But Chrome didn't really go all-in on solving problem #2, they kind of had this weird hybrid approach where they were still trying to stop the data from being streamed, but not always, and if you muted the video it would still be streamed, but if you didn't it wouldn't...
So it became the worst of both worlds.
At the time I argued (and I still think this would be a better approach) that given that the goal was entirely about stopping audio, this should have all been handled through automatic tab muting, not through a change to the web APIs.
That's not to say that blocking large amounts of data or stopping the visual aspects of videos isn't important, but the approach Chrome went with (and that Firefox has subsequently inherited) kind of does nothing well. And I think we still see the effects of that today, even in browsers like Firefox that were admittedly a bit more sensible about not adapting some of Chrome's worst ideas.
Interactions were also a sticking point: Chrome interpreted even highlighting text as a signal that autoplay should be allowed -- which is obviously very easily abusable. I generally think that the user-gesture requirement for permissions is not great; it severely limits what users can do on a page while still signaling that they don't want to grant permission for a random action like autoplaying audio.
It's a tricky problem to solve, but I also think it's a problem that's harder to solve because of some of the previous baggage we've inherited from previous efforts to solve it.
I use Safari instead of Chrome when I want twice the autonomy, and it's really strict to websites trying to play media without interaction. It doesn't even start loading YouTube videos until I click the giant play button. You never even see that button in Chrome, and I can't believe how much I now miss that basic sanity check. Chrome will even start playing dozens of tabs simultaneously if I open a collection of tabs from Bookmarks. Really think there should be a setting that enforces the requirement of initial interaction before playback on every site in all browsers.
