Add properties/mechanism to get clientWidth/Height of the visual viewport in unscaled coordinates
Opened this issue · 6 comments
I believe the intent of the spec currently is to return lengths/offsets in the layout viewport's coordinate space -- e.g. as I zoom in, the visual viewport's clientWidth and clientHeight properties "shrink".
However, pending the addition of real device-fixed positioning, it's interesting to additionally receive these properties in the coordinate space of the visual viewport (basically just unaffected by pageScale). Since these elements are laid out in the visual viewport's coordinate space, it's more convenient to receive the measurements in the visual viewport's coordinate space directly rather than multiplying by pageScale (and introducing risk of floating point error).
I imagine other scenarios could also benefit from this, but that's the one that immediately pops into my mind for now :)
Once the visual viewport API ships, I think the plan is to make properties like window.innerWidth and innerHeight "unaffected by pageScale". Are you suggesting to have this as part of visualViewport as well?
Right, these properties are already available elsewhere (outerWidth/Height, in Chrome at least). Adding multiple values in visualViewport might get confusing and we'd have to invent some terminology to differentiate them so I'm partial to keeping this simple. Additionally, for the device-fixed case, presumably the author could use percentage based sizses and left/top/right/bottom positioning so I'm not sure how useful it would be.
I'm assuming though that innerWidth/Height and outerWidth/Height, even if made to be unaffected by pageScale, will not adjust for visual viewport clipping (e.g. what Edge does when the on-screen keyboard is invoked), so this would still require some calculation from the dev. Or do you expect innerWidth/Height to resist scaling but adhere to clipping?
I'm not well acquainted with Edge's on-screen keyboard so I'm not sure I fully understand your concern. Our preferred model is what ChromeOS uses today: the OSK shrinks the visual viewport but not the layout viewport. This means that once we make the change to make innerWidth/Height reflect the layout viewport, the OSK wouldn't affect these values but it would affect the visualViewport width/height so the author can still keep things above the keyboard by sticking things to the visual viewport's edge (it'll be kept there regardless of whether changed by zooming or clipping).
I think this is the situation you refer that'll require "calculation from the dev", what's the particular concern? The intent is that the page shouldn't react in any way to the OSK coming up unless the author has explicitly "opted-in" to adjusting the UI for it, similarly to how we want pinch-zoom to work.
The short version is "how do I get the height of the visual viewport in the visual viewport's coordinate space?"
Right now I think it's something like visualViewport.clientHeight * visualViewport.scale, which is less than ideal due to the risk of floating point error I mentioned above as well as just convenience. innerHeight will be inaccurate when the keyboard is up, so it doesn't work as a substitute.
To clarify, I don't think this is strictly necessary for a v1, but it would be a good addition particularly once we standardize device-fixed.
What use case do you have in mind for this? Is it so that you could position a bar above the OSK but not have it stick to the viewport when zooming in? If so, I'm not sure that the floating point precision is necessary since once you're zoomed in you can't really tell where the bar is anyway. I made an example that shows how this works: Fixed to keyboard (No Zoom). Is that what you're looking for? (You'll need to turn on some chrome://flags, see the bottom section of README.md)
(I'm not opposed to adding this, just want to make sure we have a good reason to)