Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rationalizing with declarative CSS and visualViewport concepts #12

Open
dlibby- opened this issue Feb 24, 2021 · 0 comments
Open

Rationalizing with declarative CSS and visualViewport concepts #12

dlibby- opened this issue Feb 24, 2021 · 0 comments

Comments

@dlibby-
Copy link
Collaborator

dlibby- commented Feb 24, 2021

Based on what we've discussed in the past, having the declarative form match this imperative API is important for both future extensibility and limiting the number of concepts developers have to learn/be aware of.

In this solution space there are two competing goals:

  • performant layouts under common manipulations (pinch zoom, scroll). Particularly for the declarative forms.
  • rationalization (or fitting in with) existing concepts. Visual viewport has the most interactions here as it deals with things like pinch zooming, mobile frame hiding on scroll.

For performance it would be ideal if the representation is something closer to a description of the hardware, relative to the viewport at specific parameters (e.g. at constant scale factor of 1 or initial scale factor) that do not change in response to things like the mobile frame hiding. As an example, see this issue. However, it seems relatively clear that such a concept is somewhat novel and perhaps unexpected by authors (well perhaps not completely true as the only other widespread CSS environment variable safe-area-inset-* has the same behavior).

One possibility is to have the JS API more closely match VisualViewport but keep the CSS environment variables as 'static' for a given orientation/window layout.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant