Observe the element the game actually uses
Use ResizeObserver when the canvas container can change independently of the window, for example inside a split panel or a page with changing controls. Read its content size, update the canvas backing dimensions only when they differ, and recompute the scale between CSS coordinates and game-world coordinates.
Avoid writing layout-affecting dimensions back to the same observed element without a guard. MDN notes that resizing from an observer callback can create a loop; schedule work carefully and skip writes when the expected size has not changed. Keep the game viewport separate from the fixed world coordinate system when the design should letterbox rather than distort.
Test layout and input as one behavior
At narrow, wide, and rotated sizes, click or tap a target near each canvas edge and check that the game sees the same world location as the visible mark. Resize while a level is active and confirm that the camera or letterboxing policy is applied without changing positions unexpectedly.
Observe the container rather than assuming window.innerWidth captures every layout change. If a mobile keyboard or browser chrome changes available space, decide whether the playfield should shrink, remain fixed, or scroll. Test that choice with controls visible, since controls can consume space the game needs.
Questions about browser game resize handling
Should every resize change the game world size?
No. Many games retain stable world coordinates and change only the camera or letterboxing. Resizing the world itself can affect difficulty, collision, and level composition.
When is ResizeObserver preferable to a window resize handler?
Use ResizeObserver when the relevant element can change size because of its container or surrounding layout, even if the overall window dimensions stay the same.