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
The name "PauseFrame API" seems problematic to me, because "frame" already means at least three different things on the Web platform:
an element that holds a subdocument (as in <iframe>)
a tick of an animation or of the browser refresh cycle (as in requestAnimationFrame())
a stack frame in JS
Associating the words "pause" and "frame" together leads me, and I suspect others, to assume that frame in this context is usage (2) (i.e., that this is an api about animations) rather than usage (1).
My inclination is that you should probably avoid the term "frame" in the title of the specification because of this potential confusion, and because of the (maybe) general principle that overused/confusable terms should be used as little as possible.
I'm not sure if that implies anything about the names exposed in the API surface...
(I got here from w3ctag/design-reviews#196. But just my own opinion at this point; not speaking for the TAG.)
The text was updated successfully, but these errors were encountered:
Pause Document or Pause IFrame both seem reasonable to me. I went with frame over iframe because we ought to include frames as well. Pause Document accomplishes that.
The name "PauseFrame API" seems problematic to me, because "frame" already means at least three different things on the Web platform:
<iframe>
)requestAnimationFrame()
)Associating the words "pause" and "frame" together leads me, and I suspect others, to assume that frame in this context is usage (2) (i.e., that this is an api about animations) rather than usage (1).
My inclination is that you should probably avoid the term "frame" in the title of the specification because of this potential confusion, and because of the (maybe) general principle that overused/confusable terms should be used as little as possible.
I'm not sure if that implies anything about the names exposed in the API surface...
(I got here from w3ctag/design-reviews#196. But just my own opinion at this point; not speaking for the TAG.)
The text was updated successfully, but these errors were encountered: