Re: [w3ctag/design-reviews] WG New Spec: Scroll-Triggered Animations (Issue #1167)

DavMila left a comment (w3ctag/design-reviews#1167)

Thanks for the questions

> 1. Regarding the use of `contain` and `cover`: we think this is going to cause developer confusion - whilst re-using syntax is generally a good thing, it seems that the meaning of the keywords here diverges from how they're used in CSS in general. Has the group discussed alternative names - if they were rejected, could you point us to the rationale?

Oh, valid point. I agree that the meaning isn't quite the same as with properties like `object-fit` and `background-size` which I just looked up. However I would point out that this feature doesn't actually introduce this interpretation of those keywords or the use of these keywords in the context of timelines. It is only adhering to what was adopted when timelines were introduced in [scroll-driven animations](https://github.com/w3ctag/design-reviews/issues/828). In addition, I don't think we've received feedback, since the launch of SDA, suggesting this is an issue for developers, so perhaps the context is different enough from the other properties that it mitigates the fact that it is a different use of the keywords, which I agree with.
  
> 2. Should the UA have some control over the speed of these animations in particular? Regarding the issue that they could be distracting for people, or simply happen too fast for some people to process (both of these could affect anyone who is distracted, or has specific cognitive disabilities).
>    As these are a 'new' type of animation (from the spec's perspective), perhaps there's an opportunity to consider whether we could give more agency to the UA in how they are rendered?
>    Specifically, if there's an opportunity here to make steps towards [giving users more control over motion](https://github.com/w3ctag/gaps/issues/15), it would be good to do so.

I think it could be a good idea for the UA to control over the speed of these animations. This feature may actually be a positive step towards that possibility from the point of view that prior to this feature, even though scroll-triggered animations exist, user agents have no concrete concept of what a "scroll-triggered animation" is because it's probably all carried out by script in various different ways. So you could have no reliable way to offer a user the option to "disable all scroll-triggered animations." With this feature I think it becomes more of a possibility, and I think this feature could help with exploring good options for what UA control over scroll-triggered animations should look like.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1167#issuecomment-4406850883
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1167/4406850883@github.com>