Intent to Ship: window.visualViewport
David Bokan
Contact emails
bo...@chromium.org, yma...@chromium.org
Spec
ED spec
WICG GitHub repo
We'd likely need to do more like spec `visual viewport` and `layout viewport` but we have pretty good agreement on what these mean colloquially.
Didn't know about TAG reviews, I requested here. The API is pretty small and self contained so I don't expect problems but we can block this on getting the review if OWNERs think it's needed.
Summary
Explicitly expose properties of the visual viewport through a `window.visualViewport` object.
Link to “Intent to Implement” blink-dev discussion
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
Demo link
There's examples using the API (as well as a polyfill) here
Interoperability and Compatibility Risk
As a new feature, there's little compat risk. Adding window.visualViewport may clash with existing variables but a search through HTTPArchive found no existing uses.
Interop wise, there's medium risk. This API makes most sense in the context of a split visual/layout viewport. Currently Edge and Chrome are the only browsers that do this explicitly. Safari uses a similar though somehow different model while Firefox uses a single viewport for both. For Firefox/Safari, the API still makes sense to implement - it's just more redundant in their model. We've communicated with Edge engineers (cc'd) and they've expressed interest in this API.
The API really becomes useful if we (re)fix http://crbug.com/489206 and ship http://crbug.com/404315. Currently, pinch zoom affects some window APIs like innerWidth/Height and scrollX/Y while not others (like event coordinates and getBoundingClientRect). Fixing this to make all existing APIs relative to layout viewport would mean there's no way to get the pinch-zoom affected "visual" values exposed through innerWidth/scrollX today. Without that change, visualViewport.pageX/Y and visualViewport.clientWidth/Height are redundant (though scrollLeft/Top, scale, and the events are adding new abilities).
OWP launch tracking bug
Entry on the feature dashboard
https://www.chromestatus.com/features/5737866978131968
Chris Harrelson
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
smaug
Like it dispatches events on objects which aren't EventTargets and such.
And it isn't really defined when those events fire. "may be fired asynchronously" is rather vague.
It would be hard for other implementers to implement anything compatible with blink's implementation, since its
implementation doesn't follow the current draft spec (because the spec is buggy).
-Olli
On 08/10/2016 03:06 AM, Chris Harrelson wrote:
> Hi,
>
> Some questions to document level of feedback from the standards and browser community:
>
> What level of engagement have you had so far with any existing W3C working groups that might be related to this feature? Not sure which ones would be
> the most relevant.
>
> Any detailed feedback from other browser vendors or web developers that it seems a good feature? As you mentioned in the intent, feature was in part
> motivated by pushback on the Chromium bugs you referenced toward the end. Did you run the current state by those who commented on the bug to see if
> they think it meets their needs?
>
>
>
>
> Contact emails
>
> bo...@chromium.org <mailto:bo...@chromium.org>, yma...@chromium.org <mailto:yma...@chromium.org>
>
>
> Spec
>
> ED spec <https://rawgit.com/WICG/ViewportAPI/master/index.html>
>
> WICGGitHub repo <https://github.com/WICG/ViewportAPI>
>
> We'd likely need to do more like spec `visual viewport` and `layout viewport` but we have pretty good agreement on what these mean colloquially.
>
>
>
> Summary
>
> Explicitly expose properties of the visual viewport through a `window.visualViewport` object.
>
>
> Link to “Intent to Implement” blink-dev discussion
>
> Intent-to-Implement
>
> Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
>
> Yes
>
>
> Demo link
>
>
> Interoperability and Compatibility Risk
>
> As a new feature, there's little compat risk. Adding window.visualViewport may clash with existing variables but a search through HTTPArchive
> found no existing uses.
>
>
> Interop wise, there's medium risk. This API makes most sense in the context of a split visual/layout viewport. Currently Edge and Chrome are the
> only browsers that do this explicitly. Safari uses a similar though somehow different model while Firefox uses a single viewport for both. For
> Firefox/Safari, the API still makes sense to implement - it's just more redundant in their model. We've communicated with Edge engineers (cc'd)
> and they've expressed interest in this API.
>
>
> The API really becomes useful if we (re)fix http://crbug.com/489206 and ship http://crbug.com/404315. Currently, pinch zoom affects some window
> APIs like innerWidth/Height and scrollX/Y while not others (like event coordinates and getBoundingClientRect). Fixing this to make all existing
> APIs relative to layout viewport would mean there's no way to get the pinch-zoom affected "visual" values exposed through innerWidth/scrollX
> today. Without that change, visualViewport.pageX/Y and visualViewport.clientWidth/Height are redundant (though scrollLeft/Top, scale, and the
> events are adding new abilities).
>
>
> OWP launch tracking bug
>
>
>
> Entry on the feature dashboard <http://www.chromestatus.com/>
>
> https://www.chromestatus.com/features/5737866978131968
>
>
> --
> You received this message because you are subscribed to the Google Groups "blink-dev" group.
> <mailto:blink-dev+...@chromium.org>.
>
> --
> You received this message because you are subscribed to the Google Groups "blink-dev" group.
> <mailto:blink-dev+...@chromium.org>.
David Bokan
Clearly that spec at least isn't at the level where implementations should ship.
Like it dispatches events on objects which aren't EventTargets and such.
And it isn't really defined when those events fire. "may be fired asynchronously" is rather vague.
David Bokan
Hi,Some questions to document level of feedback from the standards and browser community:What level of engagement have you had so far with any existing W3C working groups that might be related to this feature? Not sure which ones would be the most relevant.Any detailed feedback from other browser vendors or web developers that it seems a good feature? As you mentioned in the intent, feature was in part motivated by pushback on the Chromium bugs you referenced toward the end. Did you run the current state by those who commented on the bug to see if they think it meets their needs?
Matt Rakow
I’m supportive of an explicit visual viewport API and I expect we will implement eventually, though it’s low priority for us right now since existing APIs expose this functionality already and we haven’t heard high demand for it. I think the idea of removing that functionality from the existing APIs and offering the visualViewport API as replacement is interesting but I have some concerns with mobile web compat as I’ve voiced previously. If those concerns are proven unfounded then we may be interested in also taking that path, but again with low priority as it isn’t a significant source of bugs or complaints for us currently.
The current draft seems at least in the ballpark of where it should be, you can see my issues raised on Github for where I think the shape should change or be extended. Moving to a WG sounds like a reasonable next step to me; getting more diverse opinions is valuable to confirm we aren’t working in an echo chamber. Particularly considering that Edge/Chrome have matching notions of visual/layout viewport it would be good to solicit impressions from the other vendors.
Thanks,
-Matt