You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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
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
provide separate getters and setters where only the setter allows FramesPerSecond or AnimationFrameRatePreset
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.
Having an attribute which value is either a string or number (from JS point of view) is rather surprising.
The text was updated successfully, but these errors were encountered: