Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[animation-frame-rate] attribute (FramesPerSecond or AnimationFrameRatePreset) frameRate; is surprising #86

Open
smaug---- opened this issue Dec 15, 2021 · 2 comments
Labels
animations useful for animation-related explainers

Comments

@smaug----
Copy link

Having an attribute which value is either a string or number (from JS point of view) is rather surprising.

@graouts graouts added the animations useful for animation-related explainers label Dec 15, 2021
@graouts
Copy link
Contributor

graouts commented Dec 15, 2021

First, let me explain why we made this proposal.

We felt it was important that known values, those from the AnimationFrameRatePreset enum, could be used to communicate simple intents such as "I want the highest frame rate possible" or "feel free to use a lower frame rate for this low-impact animation". It's equally important that authors who know what specific frame rate they would like their animation to run at could specify a numeric value. This is why we allowed a FramesPerSecond or AnimationFrameRatePreset value.

In order to allow this value to be round-tripped and shared across several animations, we felt it was important that it could be read back as-is without being computed.

I think there are several ways this could be addressed:

  1. only allow FramesPerSecond or AnimationFrameRatePreset when specifying the frameRate as the options parameter to calls to Element.animate() or the Animation constructor and leave the frameRate property itself only be FramesPerSecond
  2. keep the property as-is but expose a computedFrameRate property that exposed the resolved value based on display refresh characteristics, which may affect AnimationFrameRatePreset values as well as explicit FramesPerSecond values
  3. provide separate getters and setters where only the setter allows FramesPerSecond or AnimationFrameRatePreset

There may yet be other options.

@flackr
Copy link

flackr commented May 10, 2022

I agree I find this very confusing. In particular, the actual values applied for { "auto", "low", "high", "highest" } seem like they would be hard to predict, and could easily vary from device to device or UA to UA. Is what is defined as "high" now going to change in the future if the expected high animation rate increases?

I think if the only special case is making animations run as fast as possible, we could flip the value to be the interval between ticks rather than the framerate. This way, a developer could specify 0 to indicate to the browser to animate as fast as it can.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
animations useful for animation-related explainers
Projects
None yet
Development

No branches or pull requests

3 participants