Intent to Implement: Visual Viewport API

[Yash]

Contact emails

bo...@chromium.org, yma...@chromium.org

Spec

Currently, there is no spec for exposing the visual viewport to the web. A part of the work here is to have one.

Summary

Add an API to expose visual viewport information to the Web.

The current proposal (which we will probably iterate on) is to add a viewport object on document.scrollingElement.

viewport = {

   double scrollTop;  // Relative to the layout viewport

   double scrollLeft; // and writable.

   double clientWidth;  // Read-only and excludes the scrollbars

   double clientHeight; // if present.

   double pageScale;

}

See this doc for more details.

Motivation

In the current state of things, CSSOM scroll properties are relative to the visual viewport (see this for list). There is no spec governing this, but this is how browsers have it implemented today. With this implementation, the dimensions of the visual viewport can be easily determined (For example, window.innerHeight = visual viewport height).

Though, having CSSOM scroll properties relative to the visual viewport breaks many sites under pinch-zoom (see crbug.com/489206) . Because pinch-zoom was intended to be more for legacy websites and we had little insights as to why a developer would need to know the visual viewport dimensions,  it was concluded that it would be a fairly low-risk change to make it invisible to developers. In addition to this, the failure mode of the change would be user friendly since things that would react to pinch zoom would stay static, which in many/most cases would feel like the intuitive zoom behaviour to the user.

M48 shipped a change that made these CSSOM properties relative to the layout viewport (Intent to ship). This change had to be reverted because more than anticipated sites were relying on it. For example, one legitimate use case was that of a screen casting app, that would cast the viewport content (see crbug.com/571297 for more examples).

From all the developer feedback, it’s clear that the visual viewport information needs to be exposed to developers.

Interoperability Risk

Firefox and safari have a different pinch to zoom model.

Edge follows the same model as Chrome and moving forward, we would like to get their feedback on this and have them implement it as well.

Compatibility Risk

Low because this is a new API and we’re not breaking any compatability.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

https://crbug.com/595826

Requesting approval to ship?

No

[David Bokan]

To further motivate this, the reason we want to change these CSSOM properties to be relative to the layout viewport is that most other properties already are (e.g. getBoundingClientRect, elementFromPoint, Event coordinates, etc.). Having this mix is a confusing foot gun.

When mobile browsers came out they made the innerWidth/Height and scrollX/Y represent the visual viewport assuming that the visual viewport == layout viewport on desktops. Because this is often true, developers don't design desktop pages thinking about this and so desktop pages are often broken on mobile when pinch-zoomed. More importantly, features like pinch-zoom and on-screen keyboards (OSK) are making their way to more and more desktop users. Prominent web sites (e.g. Facebook) have broken UI when pinch-zoomed on a desktop browser (or having the OSK come up in CrOS).

I would also like to add that our plan here is to reintroduce the change that was reverted in M48 after we ship this and give authors some time to transition their content. Given that, I would say that the overall compat-risk is non-trivial but our experience having it hit stable in M48 shows that it's a manageable amount of pain. We're also designing this in concert with Edge so we wouldn't want to ship something until they're happy with it and agreed to ship as well.

[Simon Pieters]

On Thu, 17 Mar 2016 22:01:21 +0100, Yash <yma...@chromium.org> wrote:

>
>
> Contact emails
>
> bo...@chromium.org, yma...@chromium.org
>
> Spec
>
> Currently, there is no spec for exposing the visual viewport to the web.
> A
> part of the work here is to have one.
>
> Summary
>
> Add an API to expose visual viewport information to the Web.
>
> The current proposal (which we will probably iterate on) is to add a
> viewport object on document.scrollingElement.
>
> viewport = {
>
> double scrollTop; // Relative to the layout viewport
>
> double scrollLeft; // and writable.
>
> double clientWidth; // Read-only and excludes the scrollbars
>
> double clientHeight; // if present.
>
> double pageScale;
>
> }
>
> See this doc

> <https://docs.google.com/document/d/1Y4qcIO9RyfxFR9KHsVtlDxKUSHV8iUxd1uUZUl7fT1U/edit?usp=sharing>
> for more details.

I think it could be a good idea to send this proposal to www-...@w3.org
with [cssom-view] in the subject, or file a bug[1] so the CSSWG can
evaluate the proposal and give feedback and, when the timing is right, we
can put it in the CSSOM View spec (and fix whatever else needs fixing in
CSSOM View, like window.innerHeight).

[1]
https://www.w3.org/Bugs/Public/enter_bug.cgi?product=CSS&component=CSSOM%20View

cheers

> Motivation
>
> In the current state of things, CSSOM scroll properties

> <https://drafts.csswg.org/cssom-view/> are relative to the visual
> viewport
> (see this
> <https://docs.google.com/document/d/1ZzzvA_AuMDa_nlwIc9PdpzfIXsgrOZDixFvEFwrfXJM/edit?usp=sharing>

> for list). There is no spec governing this, but this is how browsers have
> it implemented today. With this implementation, the dimensions of the
> visual viewport can be easily determined (For example,
> window.innerHeight =
> visual viewport height).
>
> Though, having CSSOM scroll properties relative to the visual viewport
> breaks many sites under pinch-zoom (see crbug.com/489206

> <https://crbug.com/489>) . Because pinch-zoom was intended to be more for

> legacy websites and we had little insights as to why a developer would
> need
> to know the visual viewport dimensions, it was concluded that it would
> be
> a fairly low-risk change to make it invisible to developers. In addition
> to
> this, the failure mode of the change would be user friendly since things
> that would react to pinch zoom would stay static, which in many/most
> cases
> would feel like the intuitive zoom behaviour to the user.
>
> M48 shipped a change that made these CSSOM properties relative to the
> layout viewport (Intent to ship

> <https://groups.google.com/a/chromium.org/d/msg/blink-dev/mt1uciFuvWQ/ecQi0f8kCQAJ>).

> This change had to be reverted because more than anticipated sites were
> relying on it. For example, one legitimate use case was that of a screen
> casting app, that would cast the viewport content (see crbug.com/571297
> for
> more examples).
>
> From all the developer feedback, it’s clear that the visual viewport
> information needs to be exposed to developers.
>
>
> Interoperability Risk
>
> Firefox and safari have a different pinch to zoom model.
>
> Edge follows the same model as Chrome and moving forward, we would like
> to
> get their feedback on this and have them implement it as well.
>
> Compatibility Risk
>
> Low because this is a new API and we’re not breaking any compatability.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> Yes.
>
> OWP launch tracking bug
>
> https://crbug.com/595826
>
> Requesting approval to ship?
> No
>

--
Simon Pieters
Opera Software

[David Bokan]

I think it could be a good idea to send this proposal to www-...@w3.org with [cssom-view] in the subject, or file a bug[1] so the CSSWG can evaluate the proposal and give feedback and, when the timing is right, we can put it in the CSSOM View spec (and fix whatever else needs fixing in CSSOM View, like window.innerHeight).

[1] https://www.w3.org/Bugs/Public/enter_bug.cgi?product=CSS&component=CSSOM%20View

 

Agreed we'll want to do this soon but right now we'd like to implement, get some experience using it, and convince ourselves this is a good design. Once we're ready to move forward we'll reach out.

[Elliott Sprehn]

This doesn't seem right to me, document.scrollingElement is an Element, you shouldn't be throwing extra objects onto HTMLBodyElement and HTMLHTMLElement like that.

I don't think we should be adding properties to Element about the viewport.

[David Bokan]

What's the problem with putting it on an Element? The reason we'd like to put viewport on document.documentElement (scrollingElement was a mistake, see discussion in doc) is for future extensibility. Edge has -ms-content-zooming and if we ever decided to standardize that or something similar we could naturally extend this by letting other elements have a viewport too. 

[Rick Byers]

It seems far from certain that we'll want to standardize something like ms-content-zooming (even the MS folks I've talked to about it aren't too excited about it).  But I agree we should be considering potential future extensibility.

That said, I don't see a real benefit to putting it on Element until such time as it would really be useful there.  Maybe it should just be on Document (or even navigator) for now, but designed so that it could be added to Element (probably as a nullable property) in the future?

Anyway this is probably the sort of design question probably best discussed in a GitHub issue.  When you have a repo, can you move this discussion there and update this thread?

[Elliott Sprehn]

Any element can be the documentElement, that means you're extending the global interface to have a concept of viewport which doesn't seem right. Having this property on thousands of elements but only ever non-null on a single one per page (for the lifetime of the page) is very strange. Especially since if I remove the documentElement there still is a viewport.

[David Bokan]

GitHub repo and issue filed @ https://github.com/bokand/ViewportAPI/issues/1