Fix #27666 Inconsistent use of window.requestAnimationFrame v requestAnimationFrame

[skyclouds2001]

Description

Motivation

Additional details

Related issues and pull requests

#27666

note that this may not a fix to #27666, as the issue creator suggest that use requestAnimationFrame instead of window.requestAnimationFrame, but in my view below, it is better to use window.requestAnimationFrame, reasons are below

and @blindman67 did not give further response anymore

[github-actions]

Preview URLs

• /en-US/docs/Web/API/Canvas_API/Tutorial/Basic_animations

(comment last updated: 2024-03-13 10:07:29)

[skyclouds2001]

@blindman67 I wonder if this contribution fix your issue, as I am not quite understand your meaning

[blindman67]

@skyclouds2001 No not fixed.

window is the default this and its use in the examples is redundant. IE window.requestAnimationFrame is the same reference as requestAnimationFrame

In the example code the use of window is inconsistent (across all examples). It is used with window.requestAnimationFrame but not with window.document.createElement or new window.Date() and many more window properties used in the examples.

[skyclouds2001]

@skyclouds2001 No not fixed.

window is the default this and its use in the examples is redundant. IE window.requestAnimationFrame is the same reference as requestAnimationFrame

In the example code the use of window is inconsistent (across all examples). It is used with window.requestAnimationFrame but not with window.document.createElement or new window.Date() and many more window properties used in the examples.

Well, @blindman67 I understand what you mean now completely

And my opinion is that, whether we use window.xx or xx might can be judged by following reasons:

• whether the variable is in Web API standard or in ECMAScript standard (if in ECMAScript standard, it shouldn't relate with window)
• whether the variable is defined as a property on Window interface or just simply expose to global scope (in main context it is the window) (if just simply expose to global scope, it shouldn't visit via with window)
• whether the variable is a well-known symbol (if well-known enough, can simply by avoiding visiting via window)
• wether other developers may confuse the variable as a custom variable (if the name of the variable is commonly used in other cases, it'd better to use it via window)

For example:

• prefer using document instead of window.document, since document property is well-known enough and develpors wouldn't confuse it as a custom variable
• prefer using Date instead of window.Date, since Date is exposed to global scope not defined on Window interface and Date is a ECMAScript standard, not a Web API standard
• prefer using window.print() instead of print(), since print is a commonly used symbol and may be comfused by other developers

Here I think use window.requestAnimationFrame() is better

[skyclouds2001]

see also #10573 (comment) and #30329 (comment)

[skyclouds2001]

Beside this, I agree that it is needed to consistent the usage of window.requestAnimationFrame or requestAnimationFrame

[skyclouds2001]

@blindman67 would you offer your idea on whether using window.requestAnimationFrame or requestAnimationFrame is better

[teoli2003]

Prefixing requestAnimationFrame() with window prevent to directly copy-paste the snippet into a worker code. Using self or nothing doesn't have this problem (and they still work on the Window global scope).

I have no strong feelings about these two solutions (self or nothing), though we should uniformize–for sure on a given page, likely everywhere– and I don't see a benefit of self..

cc/ @wbamberg @Elchi3 that may have some extra insight here.