@bokan, I have some questions about the propose API. Please let me know if this is not the right place for these questions:
1. Can you explain why the proposed API places the `visualViewport` object on the `document` scope? I don't see why it isn't on the `window` object. Especially since it seems to be something that is more closely related to the viewport than the page itself.
2. The `pageScale` variable implies that the page scales when you visually zoom, while this isn't the case. just `scale` or `zoomLevel` seem more representative of what the value returns.
3. Will there also be a suggestion for something like a `pageViewport` or `layoutViewport`? Especially since we'd like to be able to get a combined zoom level of both the visual and page viewports.
4. I have suggestion to rename the `scrollTop` to `panningTop` or `panningY`. Same goes for `scrollLeft`. This seems like a more accurate name, since the `scrollTop` value adds ambiguity. Panning values would be the values that need to be added to the detected scroll.
5. ...now that I think of it.. why are you using `clientWidth`? Shouldn't just `width` suffice?
6. Will the `window.innerWidth` still be available after proposing these changes, or should we expect that backwards compatibility will be broken?
I hope I'm not bugging you too much with these questions :).
Thanks in advance for taking the time to answer them!
3. Will there also be a suggestion for something like a `pageViewport` or `layoutViewport`? Especially since we'd like to be able to get a combined zoom level of both the visual and page viewports.
layoutViewport can be queried using similar properties in document.scrollingElement (for example, document.scrollingElement.scrollTop).
4. I have suggestion to rename the `scrollTop` to `panningTop` or `panningY`. Same goes for `scrollLeft`. This seems like a more accurate name, since the `scrollTop` value adds ambiguity. Panning values would be the values that need to be added to the detected scroll.
visualViewport.scrollTop and visualViewport.scrollLeft are analogous to 'element.scrollTop' and 'element.scrollLeft (more specifically document.scrollingElement.scrollTop/Left), where in the latter case, it's the layout viewport's position relative to the document and in the former case, it is the visual viewport's position relative to the layout viewport.
5. ...now that I think of it.. why are you using `clientWidth`? Shouldn't just `width` suffice?
Again, I think clientWidth and clientHeight is more consistent with that of it's layout viewport counterparts (document.scrollingElement.clientWidth/Height).
6. Will the `window.innerWidth` still be available after proposing these changes, or should we expect that backwards compatibility will be broken?
window.innerWidth, and others will be made relative to the layout viewport as proposed in issue 489206 .
As usual, I disagree with the last statement: window.innerWidth/Height should continue exposing the visual viewport dimensions for reasons of backward compatibility and cross-browser compatibility. (EVERY other browser does so, including the ones no one but me has ever heard of. Chrome cannot unilaterally change a de-facto standard.)
Other than that I like the current proposal as a starting point; it certainly covers the most important areas.
One question about pageScale: this measures the visual viewport's scale relative to WHAT?
Is it relative to the layout viewport? That sounds logical, but right now the scale directive in the meta viewport is relative to the ideal layout viewport (the one you get when you do width=device-width), even when the layout viewport has different dimensions. I couldn't figure out the answer by looking at the code example, since it doesn't include the <head> and we don't know if it contains a meta viewport or not.
Also, I'm in favour of dropping the weird Apple-speak 'scale' for 'zoom', which is what you would expect. So pageZoom, or possibly viewportZoom, or just zoom.
Finally, I'm somewhat sympathetic to the idea of adding this API to window instead of document. I see why you'd want to maintain equivalency between document.documentElement.clientWidth and document.visualViewport.clientWidth, but strictly speaking the visual viewport is not a part of the document. So there's a tension here.
Re #4:
1) We're somewhat averse to adding properties to the `window` object since it'll more likely conflict with variable names in use by apps
2) I'm not really sure what you mean about the page not scaling but we probably have a different notion of `page`. That said, you're right that `scale` or `scaleFactor` is probably just as good without any additional terms so that may make more sense (zoom is typically reserved for Ctrl+/- type zooming).
3) To add to ymalik@'s answer, document.scrollingElement.clientWidth/Height currently refer to the layout viewport *but* document.scrollingElement.scrollTop/Left refer to the visual viewport. The only way I know of today to get the position of the layout viewport is keeping an invisible, position: absolute, dummy element at window.scrollX/Y and getting its location relative to the layout viewport using getBoundingClientRect. If you then subtract that location from window.scrollX/Y you get the layout viewport's location. I have a half-baked test page kind of demonstrating this: bokan.ca/demo/vvapi/test.html *duct-tape alert*
As you can see, it's completely arbitrary what viewport various properties relate to and this is one of the reasons we'd like to make window.innerWidth/Height and scrollX/Y refer to the layout viewport.
5) clientWidth is used to make it clear that scrollbars are not included in the dimensions (analogous to Element.clientWidth)
Re #6:
>One question about pageScale: this measures the visual viewport's scale relative to WHAT?
pageScale is the scaling factor applied to the pixels on the page. In the absence of `browser zoom` (ctrl+/- zooming), this would be the ratio of DIPs to CSS pixels.
>Is it relative to the layout viewport? That sounds logical, but right now the scale directive in the meta viewport is relative to the ideal layout viewport (the one you get when you do width=device-width), even when the layout viewport has different dimensions. I couldn't figure out the answer by looking at the code example, since it doesn't include the <head> and we don't know if it contains a meta viewport or not.
It's the same as `scale` in the viewport meta and so relative to the "ideal layout viewport". That is, scale=1 means that 1 CSS pixel == 1 DIP. I'll update the explainer to make that clearer.
>Also, I'm in favour of dropping the weird Apple-speak 'scale' for 'zoom', which is what you would expect. So pageZoom, or possibly viewportZoom, or just zoom.
I worry about adding to the confusion between `browser zoom` (ctrl+/-) and `pinch zoom`. Internally, our terminology is that pinch-zoom applies "scale" and ctrl+/- applies zoom. Though maybe since it's on the visualViewport object it's clear enough? I'd be ok calling it viewport.zoom; we'll see what other browser implementors think.
> Finally, I'm somewhat sympathetic to the idea of adding this API to window instead of document. I see why you'd want to maintain equivalency between document.documentElement.clientWidth and document.visualViewport.clientWidth, but strictly speaking the visual viewport is not a part of the document.
We put it on document so it doesn't clash with existing applications' namespace. I agree window might be a better place for it conceptually. Again, we'll see what other browsers think.
Re #8/#9:
Thanks!
>I worry about adding to the confusion between `browser zoom` (ctrl+/-) and `pinch zoom`. Internally, our terminology is that pinch-zoom applies "scale" and ctrl+/- applies zoom. Though maybe since it's on the visualViewport object it's clear enough? I'd be ok calling it viewport.zoom; we'll see what other browser implementors think.
I agree with @pp.k on the 'scale vs. zoom' topic. The naming convention should probably be decided based on an external user's or developer's standpoint. Other browsers might have different internal naming conventions.
For the record: This point is a lot less important to me than the following one.
> As you can see, it's completely arbitrary what viewport various properties relate to and this is one of the reasons we'd like to make window.innerWidth/Height and scrollX/Y refer to the layout viewport.
Even though I agree that the term window.innerWidth is a bit ambiguous, we have come to rely on it like this. How's about we review this change after the new visual and layout viewport variables have landed in Chrome stable? Breaking backwards compatibility seems to be something we should avoid if it is not absolutely necessary.
>Even though I agree that the term window.innerWidth is a bit ambiguous, we have come to rely on it like this. How's about we review this change after the new visual and layout viewport variables have landed in Chrome stable? Breaking backwards compatibility seems to be something we should avoid if it is not absolutely necessary.
This was hotly debated in issue 571297 so I don't want to rehash here but in any case we'll land this API first and separately.
There's been some great design discussion here, thanks! But please
remember to file the essential debates as GitHub issues at
https://github.com/WICG/ViewportAPI to make sure everyone can find the
history, other vendors have equal opportunity, and that any substantial
contributions get IP protection.
I just used the experimental visualViewport API in Canary. The returned pageScale values were very useful
for my WebGL stuff.
1. The viewport.clientWidth, however, seems to include the space taken by a scrollbar (tested on a desktop browser window) while the proposed spec says it does not. I think this behaviour is good on the one hand side, because it more closely resembles the windows.innerWidth while on the other hand it is bad for positioning something device-fixed on the right, because it might be covered by the scrollbar.
2. I tried to run the example from the proposed spec in Version 52.0.2710.0 canary (64-bit) by copying the example to a file and opening it with developer tools emulating a S5 phone. When pinch-zooming in the bottom bar moved out of the screen.
3. When using viewport.clientWidth inside a document that is displayed inside an iframe, it returns a width that is far bigger than the complete document, possibly the viewport of the enclosing document.
4. On a desktop viewport.clientWidth does not seem to honor the browser zoom level.
Thanks! This is all highly useful feedback!
1. I'll look into this, if true that's definitely a bug in our implementation. I think "exclude scrollbar" is probably much more useful, as you mention.
2. I wrote that without having an implementation to test on :). I'll take a look and fix it.
3. Thanks, another potential bug I'll look at.
4. Right, I hadn't thought much about how the zooms interact but my instinct is that visualViewport.clientWidth should be in CSS pixels and so be affected by the browser zoom level. I'll take a look.
Hi everyone. Chrome Canary should now have an initial implementation of the visual viewport API behind a runtime flag. You can see the details and some examples here: https://github.com/WICG/ViewportAPI. The visual viewport API can be turned on with chrome://flags/#enable-experimental-web-platform-features. Please try it out and feel free to file GitHub issues with feedback/suggestions/criticisms/etc.
Thanks!
The following things are remaining here:
- Writing supporting web platform tests
- Improving the spec based on feedback received on WICG (https://github.com/WICG/ViewportAPI/issues)
Comment 1 by ymalik@chromium.org
, Mar 17 2016