Taken up at Tokyo f2f. We are happy with these changes, pending an update to the explainer. Thank you for making the changes. We'd like to additionally suggest that, in accordance with our draft design guidelines, since visual viewport can fire events there should be handler attributes present, specifically onresize and onscroll.

The one other thing I wanted to look into (along with @plinss and @travisleithead) was about X/Y vs. Left/Top naming. I tend to prefer Left/Top naming since it extends better to other directionalities, and I have a suspicion that X/Y naming is currently used in the platform more for points than rectangles, but I want to examine further.

I've updated the explainer (but not examples/polyfill, will need to do that after updating Chrome's implementation). I've also added event handler attributes to the spec. Thanks!

There's a long list of interfaces I've found (searching Mozilla's WebIDL) that use X/Y naming. The vast majority of them are for points, deltas, or things like sizes of blurs, not for rectangles. I think window.screenX/Y and MediaTrackConstraintSet.viewportOffsetX/Y are the only examples of X/Y naming in this list that are for rectangles, which is what the new proposed naming in the Viewport API is doing.

• CanvasRenderingContext2D.shadowOffsetX/Y
• DOMMatrix (various parameters and methods)
• Document.createTouch() parameters
• DragEvent.initDragEvent() parameters
• MediaTrackConstraintSet.viewportOffsetX/Y (which goes along with viewportWidth/Height), and the same for MediaTrackSupportedConstraints
• various properties on MouseEvent and UIEvent
• parameters to MouseEvent.initMouseEvent() and MouseScrollEvent:initMouseScrollEvent()
• PannerOptions.positionX/Y/Z and orientationX/Y/Z, and same on PannerNode
• PointerEvent.tiltX/Y
• a pile of things in SVG that I don't want to list all of
• various properties on Touch
• parameters to WebKitCSSMatrix
• WheelEvent.deltaX/Y
• window.screenX/Y, scrollX/Y, pageX/YOffset

There's a slightly larger amount of Left/Top naming for rectangles (although much less in general): Element.scrollTop/Left, Element.clientTop/Left, HTMLElement.offsetTop/Left, Screen.availTop/Left. All of the Left/Top naming in the platform that I found (searching Mozilla's WebIDL) appears to be for positions of rectangles.

So I still think I somewhat prefer Left/Top naming, but if others disagree I guess I'm not in a position to insist.

And to clarify the reason I prefer Left/Top naming: we might at some point want Right or Bottom offsets, giving the inset of the right edge of the visual viewport from the right edge of the layout viewport, etc., or logical offsets giving the offsets on the block-start or inline-start sides. Or somebody might want to make a library that provides such offsets. These seem like they might be useful when pages are developed for other directionalities, e.g., direction:rtl (Arabic, Hebrew, etc.) or writing-mode:vertical-rl (vertical Chinese, vertical Japanese, etc.), or writing-mode: vertical-lr (Mongolian, Manchu, etc.).

Using X/Y naming mostly forecloses the possibility of moving in that direction in the future, whereas Left/Top naming doesn't.

@bokand: curious if you (or others) have any comments on the issue of X/Y vs. left/top naming discussed in the previous two comments?

Sorry for the delay. I don't have a strong opinion one way or the other. X/Y is a little more succinct but I buy your arguments about directionality and future extension so using Left/Right sgtm. I'll update the spec today.

Agreed closed on teleconference 16 May 2017

@dbaron + others: It turns out there's some compat risk in introducing view on the global object. See Viewport API #42. I've decided to revert the name back to view.visualViewport. I don't think TAG had a problem with this name but just to be sure, could someone confirm that this seems ok?

I'm OK with it. Not sure if other TAG members had opinions, but I don't think it had come up.