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
{{ message }}
Repository navigation
[animation-frame-rate] attribute (FramesPerSecond or AnimationFrameRatePreset) frameRate; is surprising #86
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.
Activity
graouts commentedon Dec 15, 2021
First, let me explain why we made this proposal.
We felt it was important that known values, those from the
AnimationFrameRatePresetenum, 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 aFramesPerSecond or AnimationFrameRatePresetvalue.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:
FramesPerSecond or AnimationFrameRatePresetwhen specifying theframeRateas theoptionsparameter to calls toElement.animate()or theAnimationconstructor and leave theframeRateproperty itself only beFramesPerSecondcomputedFrameRateproperty that exposed the resolved value based on display refresh characteristics, which may affectAnimationFrameRatePresetvalues as well as explicitFramesPerSecondvaluesFramesPerSecond or AnimationFrameRatePresetThere may yet be other options.
flackr commentedon 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.