Rossen: a complicated one. I've been wondering how unstable... There's only one new step added in the pipeline, between dispatching rAF and updating web animations. And that one... When I looked at this, I thought this specific updated could be unstable based on some of the layout or paint results. And I was trying to find a way to find a way in this explainer that this is addressed. They do talk about it a little bit. But I'm curious if any other TAG reviewers have answers to that.

David: something I knew something about 2 years ago and haven't looked at since.

Alice: Found the explainer hard to read because of all the animations; would like markdown to not animate GIFs by default.

Sangwhan: WebP! (So they don't show up in Safari!)

Alice: That aside, I need to have a closer read. I asked a similar question on something else to do with animations on how we might deeply integrate this with prefers-reduced-motion. I feel like that was blown off a little bit last time. Authors can use prefers-reduced-motion... but I think there should be a sensible default so that things prefers-reduced-motion disables animation effects by default unless authors specifically opt in to it. So the default shouldn't be for the prefers-reduced-motion setting to do something -- authors should have to opt in for it to do nothing.

Rossen: So today it's on to authors to stop/throttle animations based on (prefers-reduced-motion). So authors who don't care

Alice: ... or on deadline...

Rossen: ... anything engines do by default today?

Alice: I think we stop animated GIFs.

Alice: That's a good question. Chromium has code that looks at that setting other than the code that exposes it to (prefers-reduced-motion) media query, but I don't remember what that code does.

Rossen: If you don't do anything as the author, besides GIFs, sounds like nothing else stops animating.

Alice: I'd have to check -- don't remember.

Rossen: Does WebKit or Safari do more?

Tess: I'd have to ask James.

Peter: Would be interesting to have users have to opt in to animations, rather than opt out and hoping the authors respect their choice. Is there a middle ground, not switching off all forms of animation by default? Or are there subtle ones that are more ok?

Rossen: I wanted to see how much of the behavior can/should be forced onto the content. I can see a path forward where something like prefers-reduced-motion can throttle everything down by 50%, slow down timers, etc. Make it to the point where authors will have incentive to pay attention to it.

Rossen: Or you can go further -- I can see UAs going and being more forceful and stopping more than animated GIFs.

Peter: There's a lot of code that stops things like autoplaying videos. People consider a lot of these animations to be obnoxious. Can we determine obnoxiousness? How far/fast pixels are moving?

David: Maybe also users for whom slowing things down makes things worse?

Peter: Could slow things down into ranges that trigger epilepsy, could be dangerous.

Alice: Questions:

1. What should the default behavior be given that the default should respect the setting and not require authors to opt in?
2. Whose responsibility is it to figure out what the default should be and how do they do that?

Alice: Do you shut off animation by default? That could cause problems as well?

Peter: There are subtle animations that are often good for accessibility?

Rossen: Same thing for anything based on timers? Same for transitions?

Sangwhan: Feels like this could be a smaller breakout at some point.

Sangwhan: How many problems require this treatment? Does anybody really know?

Alice: Maybe the AOM meeting a good place to discuss this? (Yes.) I'll put it on the agenda.

Alice: Not sure if I should comment until we've had that discussion.

Rossen: Reasonable to ask... ?

Alice: I'll hold off for now.

Rossen: Yeah, not sure what's actionable. Today Web Animations doesn't do anything; this builds on top of Web Animations.

Rossen: Issue is pretty new.

Sangwhan: Was a previous review in #330.

(discussion about adding comments)

Peter: I'm looking at the IDL in this spec -- why object or domstring if the only valid string is an enum, why not the enum? Are there other string values?

Rossen: Looked at this in Kyoto during Houdini meeting, feedback was this (missed) -- let's see how this can work with Web Animations? Renewed proposal a year later, had timeline. Scroll timeline was introduced, started to be merged with web animations. In general, overall feature and its place in the platform is sort of the right spot. I think we're getting lost in details (plenty of them, a big feature). Does anyone think overall feature is in a bad spot in terms of where it falls in the platform?

David: I really don't remember it...

Rossen: push out by 2 weeks and hope we get to it?

Tess: Sounds good to me.

Peter: I think I answered by question about the IDL -- seems like they also take length and percentage. I'd like them to use Typed OM rather than string. Would like to start pushing people to use that instead.

Rossen: +1

Alice: question about sensible default for prefers-reduced-motion. Example from James Craig: Safari on phone lost a zoom out animation because couldn't tell which was the current tab; fixed that problem. Using that as example why you shouldn't turn off all animation when using prefers-reduced-motion. But I thought it was an example of the contrary -- probably better to close the wrong tab than going around triggering people's vestibular disorders.

Tess: Somewhere in the middle: a designer who's aware of prefers-reduced-motion and aware of it could find milder animation for that setting rather than none at all. But the default without writing any media queries, if the default is disable it, hopefully they'd know that and be able to code to that case. [...missed...]

Alice: Are user needs better forced by turning off by default or on?

Tess: Risk of creating a mechanism for users to opt back in

David: I think there have historically been two approaches to this in CSS. Some things, like Presto's handling of projection, detect the presence of a media query and have different defaults when it's present. This can behave quite badly when libraries are in use; if one library is aware of prefers-reduced-motion and has appropriately-reduced animations, and another doesn't, it leads to bad results. I think the model of color-adjust: economy | exact where things are individually designated as being OK (in this case, to print backgrounds) is a better one.

Alice: Yeah, agree that it's better to say "this animation is OK".

Alice: This discussion doesn't apply to just this API. Not sure if it makes sense to comment on this API or whether it's a broader comment for CSS WG. Should all animation APIs require an explicit opt-in to work when a prefers-reduced-motion media query would match?

Tess: I'd expect to be shot down by a compat argument that too much existing content would break...

Alice: ... stop triggering vestibular disorders.

Tess: ... seems like an improvement.

David: Is there any relevant experience from having shipped prefers-reduced-motion? Or is the interesting experience that we'd get if browsers actually disabled animations by default for reduced motion settings?

Alice: I think I've seen complaints that sites still move a lot when users enable the reduced motion setting.

(complaint about Parallax example in explainer)

Tess: Parallax example is a great example of something that should be disabled.

Alice: I think there was an Apple blog post about types of animations that tend to trigger vestibular disorders.

Alice: Should we bump the rest to next week and revisit then for rest of the API

Rossen: Main hiccup is between things that want to interact with timers/capabilities such as prefers-reduced-motion.

Alice: It's a tricky one.

Rossen: I don't believe we have a good answer based on discussions in CSSWG so far.

Peter: There's an issue on CSSWG - should we make this pending feedback

Alice: They filed an issue.

Tess: Analogy with forced-colors is good. But not all user preferences are created equal - this is "I prefer not to have seizures/motion sickness", not "I prefer dark mode".

... Could map the "reduce motion" preference to "forced-reduced-motion" MQ instead of "prefers-reduced-motion".

Alice: A lot of animations aren't problematic, and are useful.

Tess: Need some way of distinguishing parallax from...

Alice: e.g. flying focus rings

... Here is the WebKit blog post with the list of problematic animation types: https://webkit.org/blog/7551/responsive-design-for-motion/#zoom

Tess: If you ask authors to denote what their animation is doing... they're not going to do that. Hard to even get people to add alt text. People don't tend to notice things that don't affect them directly.

... Would need to be some heuristic but what? Number of elements impacted? Number of properties changed at once?

... If I was some very knowledgeable author with a very complicated site, and I wanted to handle prefers-reduced-motion by selectively disabling animations on my site but without fore-knowledge of what they are.. I could use the web animations API to figure out what animations are running... what would the risk factors be?

• Total number of animations e.g. 20 animations is probably too many?

Alice: The article lists the following triggers:

• Scaling and zooming, e.g. giving the illusion that the viewer is moving forward and backward in physical space
  • example is a subtle zoom effect on a background image which is played on mouse hover. Fix is to simply turn off the zooming effect when prefers-reduced-motion matches
• Spinning and Vortex Effects - visual elements moving in circular motions around a large portion of the page, behind still elements.
  • fix is to disable the spinning effects
• Multi-speed/multi directional movement (often parallax effects)
  • fix is to turn off parallax effects and just scroll normally
• Dimensionality or Plane Shifting
  • example is a solar array that tilts as the page scrolls.
  • Fix is to disable the tilting animation and scroll normally
• Peripheral motion, specifically horizontal movement
  • Example is an animation of leaves gently swaying near text

Tess: It's interesting that most of these examples are scroll-linked

Alice: What examples have the scroll-linked animation authors given us other than problematic ones?

• Progress bar animations... probably

... I think every other example is problematic per the WebKit blog post.

... Scaling and/or translating animations in all of the problematic examples

Tess: Rotating would be another problematic transform

... blur was in one case in the WebKit blog post - that would be a filter, rather than a transform

... scaling and translating are often "hacked" using width/height, left/top etc.

... blur could be simulated in other ways.

... 3D transforms are directly messing with perspective

Alice: I'm really tempted to say that there are so few unproblematic cases for scroll-linked animations that scroll-linked animations should need to opt-in rather than opt-out of running if the user prefers reduced motion.

Tess: There would be push-back because of the inconsistency. Not really a backwards compat issue because it's not shipping yet. Argument about inconsistency is primarily theoretical purity, also partly a learnability thing. But the user need is very clear. Still gives the author to opt-in. Sweet spot of meeting user needs and powerful enough to allow authors to do what they need to do...

... Would like opt-in to explicitly mention the risk, somehow. Would be kind of cool if the word "vestibular" were in the property value. Like you have to type out "this animation is not going to harm people with vestibular disorders", basically.

Alice: Can always copy-paste your animation into the prefers-reduced-motion block.

Tess: Would be good to give people something easily Googleable where we can attach an explanation about the harm that can be done to users. Not having that risks authors blithely copy/pasting code into prefers-reduced-motion blocks without understanding why that might harm users.

... I'm happy to try and comment to this effect.

1. The default needs to be off
2. We should have an opt-in syntax which is clear about the potential user impac

Pending extenal feedback. Monitoring.

Alice: there was an issue in CSS wg...

Alice: Looks like there's been no real progress on the prefers-reduced-motion issue. Left a comment prompting an update.

Ran out of time.

Lea: Left comment

Dan: there is a response..

Tess: if they're considering rethinking the syntax shouldn't we say cool come back to us when you do so, or not, so we can review the thing you want us to review instead of reviewing something that will radically change?

Peter: sounds right

Tess: they haven't asked us to review the alternative

Peter: last comment from Tess asking for new direction...

Tess: we've been waiting on them... should we ping again?

Rossen: I remember the discussion... at end of sept. We took some resolutions in CSS wg... Linked from our issue #6674. Resolution 29 - adopt the new direction for declarative scroll linked animation. Since then I don't see evidence that that landed into the spec. Also the discussions I see here are not challenging that direction. From what I can tell folks are working on adopting that new direction and hopefully we can have an update here. We should leave it for now.

Peter: bumped to next year

Rossen: The issue has been evolved into a rework of the proposed feature. We're closing this review and encauraging the authors to repoen/open a new one once ready.