WebKit / explainers

Explainers from WebKit contributors
371 stars 28 forks source link

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

Open smaug---- opened 2 years ago

smaug---- commented 2 years ago

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

graouts commented 2 years ago

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 commented 2 years ago

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.