Based on what we've discussed in the past, having the declarative form match this imperative API is important for both future extensibility and limiting the number of concepts developers have to learn/be aware of.

In this solution space there are two competing goals:

• performant layouts under common manipulations (pinch zoom, scroll). Particularly for the declarative forms.
• rationalization (or fitting in with) existing concepts. Visual viewport has the most interactions here as it deals with things like pinch zooming, mobile frame hiding on scroll.

For performance it would be ideal if the representation is something closer to a description of the hardware, relative to the viewport at specific parameters (e.g. at constant scale factor of 1 or initial scale factor) that do not change in response to things like the mobile frame hiding. As an example, see this issue. However, it seems relatively clear that such a concept is somewhat novel and perhaps unexpected by authors (well perhaps not completely true as the only other widespread CSS environment variable safe-area-inset-* has the same behavior).

One possibility is to have the JS API more closely match VisualViewport but keep the CSS environment variables as 'static' for a given orientation/window layout.