News for hackers. Stuff that matters.
Re:Chrome updated to temporarily remove the autoplay policy ... by donatj on Wednesday May 16, 2018 @12:56AM (#17080097)
I think sites should simply have to ask for audio permissions like they already do for camera, location or microphone.

The browser trying to figure out if I intended to play audio is way too error prone versus me just asking.

I work on an audiobook player as a developer have been fighting this junk on iOS for years, it’s nothing but trouble. If I could just secure a permission to play audio worry free it’d make my life so much easier. Right now we need to ensure that all our audio is triggered by a click event, and if it gets too many steps away from the click event itself, everything breaks. It’s literally defined and limited how we can abstract our code.

Re:Chrome updated to temporarily remove the autoplay policy ... by MrMember on Wednesday May 16, 2018 @12:59AM (#17080115)
More granular permissions would be great. I would love to have a whitelist for audio, video, any sort of animation, etc.
Re:Chrome updated to temporarily remove the autoplay policy ... by pietroglyph on Wednesday May 16, 2018 @01:05AM (#17080138)
This seems to be the right way to go... Chrome's current approach[0] is all heuristic and no user input. I think a quick "Allow" with an optional "Remember Me" would be both easier to implement and less confusing than what they have (also not a huge pain for web developers.)

[0]: https://developers.google.com/web/updates/2017/09/autoplay-p...

Re:Chrome updated to temporarily remove the autoplay policy ... by digi_owl on Wednesday May 16, 2018 @08:12AM (#17081729)
Google's ongoing approach is to remove the human from the loop. And more and more human facing projects seems to follow suit.
Re:Chrome updated to temporarily remove the autoplay policy ... by bsimpson on Wednesday May 16, 2018 @02:33AM (#17080409)
"Any sort of animation"? =(

That would make most good UIs unusable. UI animation and audio aren't remotely the same category of interruption.

Re:Chrome updated to temporarily remove the autoplay policy ... by firmgently on Wednesday May 16, 2018 @03:11AM (#17080553)
Maybe they aren't the same category but there is an indirect link (for me) in that they are both often superfluous and have negative effects on my subjective experience (eg audio: annoyance/data usage, animation: annoyance/slowdown).

I enjoy animation, in art and film. I don't want it in my UIs and always turn it off completely when I have the option. I hated it when Photoshop introduced animated zoom, inertia panning etc, but thankfully could turn those off. It's like a surgeons scalpel with a springy handle, it adds a level of abstraction and indirectness that I don't enjoy. I also prefer to use a Bic Orange razor rather than an over-engineered, sprung, 5-bladed one, because I get direct rather than fuzzy feedback.

The animations in MacOS are honestly a large reason why I don't like it and only use it when I have to. One of the arguments that is often used to justify UI animation is that it helps relate one component to another. Ok so if for some reason I'm unable to work out that the icon I just clicked in the dock caused the application it represents to open, maybe seeing the animation would help. Once. Then I know, so why do I need to see it tens of thousands of times after that, forever re-educating me on this complex relationship of interface components. When I click a button, I just want it to do its job. Not do a little dance for me first. I'm trying to get stuff done.

One of the first things I do with any new Android phone or ROM (after enabling Developer Options) is to turn off all interface animations.

Any of us who have worked with designers or worked as designers ourselves (me, both - and I've made the egotistical mistake I am calling others out for, sure) know that far too often, animations are made because some people think they look 'cool'. Then they come up with back-justifications for them.

I may not be representative of the majority but "That would make most good UIs unusable" couldn't be less true for me.

Re:Chrome updated to temporarily remove the autoplay policy ... by erikpukinskis on Wednesday May 16, 2018 @12:52PM (#17083972)
Yours isn’t a popular opinion in the UI world but I agree with you fully and there are a handful of interaction designers who question the dogma on animations.

I think animations is one of the places where a smart smartphone company could attack Apple on a UI basis...

Apple is wedded to a rich multimedia UI. It’s so tightly connected to their brand they have no voice.

But someone who came in with a low-media, animationless UI could best Apple on speed, General “UI mess”, and energy consumption. An interesting UI brand could be built around that.

Re:Chrome updated to temporarily remove the autoplay policy ... by justwalt on Wednesday May 16, 2018 @11:36AM (#17083232)
I think most of the animations in MacOS are informative and there aren’t many I can think of that are needlessly lengthy or intrusive.

The bouncing application icon lets you know the know your app’s status as it opens, and it doesn’t delay your access to a program. The window spread shows you exactly where each window will be placed so that you can quickly find the one you want, and so on.

What animations aren’t you a fan of?

Re:Chrome updated to temporarily remove the autoplay policy ... by robin_reala on Wednesday May 16, 2018 @05:54AM (#17081149)
You can disable animations in macOS and iOS too though, and that also sets the prefers-reduced-motion media query to true in Safari. Bootstrap has just added support for that, but it’s simple to add the same to any web app you’re building (typically you’d use a CSS variable for your default animation speed, and set it to 0 inside the media query).
Re:Chrome updated to temporarily remove the autoplay policy ... by jasonkostempski on Wednesday May 16, 2018 @12:52PM (#17083973)
A whitelist assumes you'll always want all media on a domain to autoplay all the time, which is very likely not the case. I have autoplay disabled in Firefox, even animated gifs have to be started manually, which is exactly what I want, it's the only way to completely avoid surprises. I've heard this is not currently possible in Chrome which seems crazy to me.
Re:Chrome updated to temporarily remove the autoplay policy ... by Ajedi32 on Wednesday May 16, 2018 @11:46AM (#17083317)
Sound is already a permission: chrome://settings/content/sound

Video is, oddly enough, not, even though "images" are.

"Any sort of animation" seems kinda tough to implement without completely breaking just about every modern site. Enforcing it would require, at the very least, disabling JavaScript and crippling CSS.

Re:Chrome updated to temporarily remove the autoplay policy ... by Buge on Wednesday May 16, 2018 @03:13AM (#17080562)
When I click the upvote button in Hacker News, and the upvote button disappears, would that be considered an animation?
Re:Chrome updated to temporarily remove the autoplay policy ... by chatmasta on Wednesday May 16, 2018 @07:59AM (#17081675)
No because there is nothing like -WebKit-transition on it.
Re:Chrome updated to temporarily remove the autoplay policy ... by pilif on Wednesday May 16, 2018 @08:40AM (#17081888)
Then people would go back to doing their animations with JS at the cost of more CPU usage, worse frame rate and worse battery life.

Finding out whether JS is currently animating an element is about as hard as solving the halting problem.

Re:Chrome updated to temporarily remove the autoplay policy ... by nitrogen on Wednesday May 16, 2018 @11:47AM (#17083331)
JS timers and element modifications could be rate limited. Far far far cry from the halting problem.
Re:Chrome updated to temporarily remove the autoplay policy ... by lsh on Wednesday May 16, 2018 @03:16AM (#17080567)
I don't think so. Definitely a state transition though.

If on click it went grey then disappeared it miiight be considered animated.

Re:Chrome updated to temporarily remove the autoplay policy ... by logicallee on Wednesday May 16, 2018 @03:40AM (#17080659)
This isn't really related but can I set Chrome somewhere to send a header to all servers saying "Yes I agree to get cookies" so that sites won't waste 10 seconds of my life making me click OK on an overlay on top of whatever I was trying to read?

(If 1 billion people spend 10 seconds 100 times over the course of a year or two - a reasonable guess for how many sites they might visit over 2 years which use cookies - this is 277,777,778 hours spent on annoying busy work. We might dollarize this to $2.7 billion in wasted user time / annoyance.)

Re:Chrome updated to temporarily remove the autoplay policy ... by esnard on Wednesday May 16, 2018 @04:45AM (#17080897)
Each website has its own implementation for the cookie notice, so it's unlikely to be possible for Chrome.

I guess a Chrome extension listing all implementations for major websites could work though.

Re:Chrome updated to temporarily remove the autoplay policy ... by moqster on Wednesday May 16, 2018 @05:01AM (#17080945)
theres a list available in ublock. just activate it in the settings.
Re:Chrome updated to temporarily remove the autoplay policy ... by logicallee on Wednesday May 16, 2018 @06:00AM (#17081172)
I don't use ublock. Anyway I request that Chrome as a first party allow me to select "I agree to all cookies" and then have it sent that as a header or something else. This really is something that only Chrome and Firefox etc can do. Preferably in the same way :)
Re:Chrome updated to temporarily remove the autoplay policy ... by swebs on Wednesday May 16, 2018 @06:27AM (#17081273)
Or even better, an option to select "I don't consent to non-exempt[1] cookies. Serve me the cookie-less page"

[1] http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm

Re:Chrome updated to temporarily remove the autoplay policy ... by angel_j on Wednesday May 16, 2018 @01:35AM (#17080225)
A Web Permissions API would be sweet, and only a decade behind mobile...
Re:Chrome updated to temporarily remove the autoplay policy ... by pjmlp on Wednesday May 16, 2018 @02:42AM (#17080435)
Everything on the Web is a couple of decades behind native development.

Given the failures of Web based OSes, where even ChromeOS had to reach for Android native apps, it shows we will never get there.

Re:Chrome updated to temporarily remove the autoplay policy ... by angel_j on Wednesday May 16, 2018 @02:58AM (#17080504)
Mobile didn't become "native" until the big players dropped their "open web" promise to throw billions at mobile. They could very easily have synthesized the two, but the profit motive and control of OS/Browser specs was too much for them.

The "open web" was ahead of "native" mobile until the point of apostasy.

Still, Mozilla could have long ago pushed a permissions API that put all web app permissions in a single modal. Instead, of course, Mozilla chased mobile (fail) and an endless sort of silly projects nobody asked for (remember web identity?).

Re:Chrome updated to temporarily remove the autoplay policy ... by yAnonymous on Wednesday May 16, 2018 @03:15AM (#17080564)
The very last thing we need is even more permission popups.
Re:Chrome updated to temporarily remove the autoplay policy ... by oneeyedpigeon on Wednesday May 16, 2018 @08:34AM (#17081849)
It would be OK if handled with a preference where the user could choose between 'always autoplay', 'never autoplay', 'ask me whether to autoplay each and every time'. Plus the ability to vary that setting on a site-by-site basis.