Feature detection of inert-visual-viewport

[Helmut-Emmelmann]

As far as I know, the inert-visual-viewport flag just changes the behavior of properties like window.innerWidth and body.scrollX. Is there any preferable/standard way to feature detect which version of the API is present? Possibly, it is the idea to simultaneously release this API change and the viewport API, in which case one could simply check for the presents of window.viewport; or is the idea to first release the viewport API and later on the inert-visual-viewport stuff?

[bokand]

inert-visual-viewport is a bit more contentious so I'd like to try ship that a release or two after visualViewport. I originally though we might use the presence of visualViewport to feature detect inert-visual-viewport but I don't think that'd work. For example, it might make sense for Firefox/Safari to ship visualViewport strictly for interoperability without switching to the Edge/Chrome model of layout/visual viewport. In that scenario, visualViewport wouldn't imply the inert change.

I can see the appeal of being able to feature detect this. I'll have to mull over how we might want to do that. Perhaps some kind of flag on visualViewport? Let me know if you have ideas!

[ymalik]

You can always do something like comparing the visualViewport.clientHeight to window.innerHeight at visualViewport.scale != 1 to check whether window.innerHeight property is relative to the visual viewport or the layout viewport (If they are the same, then --inert-visual-viewport is not on). Of course you have to account for the scrollbar size in the calculation.

[bokand]

Right, but you have no way to set the scale yet.

[bokand]

I think there's agreement now that inert-visual-viewport is the way to go - I think the presence of this API would be convenient as a way to feature detect how the old APIs behave, I've raised this on the "inert bug" in the WebKit bug tracker.