[cssom-view] layout viewport vs visual viewport

[zcorpan]

https://github.com/w3c/csswg-drafts/issues/206 is about introducing the terms "layout viewport" and "visual viewport"

https://drafts.csswg.org/cssom-view/ should use these terms instead of just "viewport".

https://docs.google.com/spreadsheets/d/11DfDDa-s1hePVwBn3PZidlPJZ9ahhkJ44dyuMiOQtrc/edit#gid=0 looks like a useful starting point.

cc @RByers

[smfr]

Is there even a spec that describes visual viewports vs layout viewports?

[zcorpan]

That's #206.

[RByers]

Note that @smfr has enabled visual viewports by default in WebKit, yay!

But we still need to try to agree on what APIs should be relative to visual vs. layout. @bokand, you said WebKit appears to make all APIs relative to visual, right? @smfr can you elaborate at all on this decision? The master bug says just to match Chrome, but that's not what we're currently doing.

The most important thing to me is interoperability followed by consistency of the API (to reduce developer confusion). If WebKit is consistent about using visual, then perhaps that's better than the blink/Edge approach of being somewhat mixed?

[bokand]

Right. The reason I have a preference for the "all-layout" (aka inert-visual-viewport) model is lots of existing content (particularly on desktop pages) isn't written to expect or tested with pinch-zoom. So making everything relative to the visual viewport has more risk of effects misbehaving or performing poorly as we zoom in (or show the on screen keyboard). Using "all-layout", existing content won't know when it's been zoomed or when the OSK shows. The API @RByers referenced allows the rare cases that do want to respond to these events to do so. That said, I don't have any real world examples of content misbehaving (since our current model isn't "all-visual") so this is largely theoretical.

I agree though that interop is our most important goal so I'm open to either solution.

[bokand]

cc @ChumpChief , thoughts?

The other issue I thought of is that using the visual viewport for window properties will make it difficult to disambiguate whether changes are coming from a desktop window resize, pinch-zoom, OSK (assuming it resizes visual), etc. without an additional API anyway so I'm not sure I see the value.

[ChumpChief]

Yeah, all-visual is definitely going to have major issues. You'd have responsive layouts changing out from under you on pinch zoom.

[bokand]

Well, by "all" I'm talking about scroll-related APIs which are documented on the last page of this doc. So layouts will break only if they're relying on one of these APIs (like window.innerWidth, window.scrollY, etc). AFAICT, most responsive layouts rely on size media queries which I think everyone can agree should be based on the layout viewport.

[ChumpChief]

I see. I think the point still holds though, instead of using media queries plenty of sites listen to the resize event, measure the (layout) viewport, and update their layout in some manner in script. If their measurements return the visual viewport they'll do something incorrect. E.g. I believe Facebook does this when applying their tinyViewport/canHaveFixedElements class to the document.

[RByers]

@smfr says he plans to change WebKit to use layout viewport co-ordinates everywhere, and so blink will do the same. Big picture we see pinch-zoom as a UA/Accessibility feature which should be completely transparent to the web platform by default.

If that's the design we all end aligning on, perhaps we shouldn't bother updating CSS specs at all? We'll have "the viewport" and "the visual viewport". Only the former will appear in any CSS specs except for (should people decide to adopt it) the VisualViewport API and possibly the device-adaptation spec.

[ChumpChief]

Re: the change in Blink/WebKit, I'm not sure I necessarily agree with pinch-zoom only being an accessibility feature, or that transparency to the web platform is the correct default as a blanket statement. I think it's highly situational to the intended usage of the API in question, e.g. the IntersectionObserver API where "on-screen visibility" is the motivating use case of the feature (see discussion in this issue). I do agree that the specific list David provided in his document all could make sense referring to the layout viewport.

If you are making another run at this change, then I take it you feel the developer feedback has been adequately addressed by the addition of the VisualViewport API?

Re: terminology, I think using the term "layout viewport" is clearer to read and makes it more obvious whether a spec intends to refer to the layout/visual viewport vs. is ignorant of the difference. I don't have a particularly strong opinion but it does seem to encourage ambiguity to leave off "layout".

Even if we do settle on just "viewport" there is still language that needs updating, e.g. the definition of "viewport" still refers to it both as a "viewing area" and influencing the layout, making it unclear whether it's referring to the visual viewport or the layout viewport.

[bokand]

I think layout as default and visual as opt-in is what we should use for all APIs unless there's a very strong reason not to do so (I have yet to see one). In general, if the developer hasn't thought about pinch-zoom (or OSK) the experience for the user is better when the API defaults to layout. The developer may have missed an edge case in her implementation but that's her own fault for not thinking about pinch/OSK, not the user's. Developers who truly care about pinch/OSK scenarios and have thought about them can and will opt in to using the visual. I think this is a better alignment of incentives -- defaulting to visual means users are punished for a developer's omissions. IMHO IntersectionObserver doesn't fall outside of this principle, I agree with Ojan's last post in the issue.

The VisualViewport API would enable all the scenarios in the developer feedback we got and in more robust ways (e.g. resize event for zoom). We would ship VisualViewport API before making the change to scroll APIs. I'm just going to go through the outstanding issues in the API repo to make sure we address anything that we'd regret shipping (especially naming).

Regarding terminology, I just posted my thoughts in this issue. In short, "layout viewport" is actually fairly misleading so I'd like to get away from it. I'm ok with using "viewport" or a more descriptive name.