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

[css-shared-element-transitions-1] Define transitions over changing viewport #7859

Closed
bokand opened this issue Oct 7, 2022 · 5 comments
Closed
Labels
css-view-transitions-1 View Transitions; Bugs only Needs Edits

Comments

@bokand
Copy link
Contributor

bokand commented Oct 7, 2022

Due to various browser UI, a transition can take place where the source and destination pages have a different size initial-containing-block and fixed/layout viewport. Some examples of UI widgets that cause this:

  • Mobile URL bar (and related hide-on-scroll browser bars)
  • Virtual Keyboard
  • Desktop browser scrollbars

For example, most mobile browsers will force a hidden URL bar to be shown when a cross-document navigation occurs. In the other direction, a showing virtual-keyboard will be hidden when a navigation occurs. We should define exactly how transitioning elements are captured, sized, and positioned in these cases to ensure a seamless transition between the two states (i.e. elements should not "jump"). Here's what we're currently implementing which we can use as a starting point for spec text, thoughts welcome.

Snapshot Viewport

We define the concept of the "snapshot viewport". This is a rect that is a consistent size and position regardless of what UI is currently shown. For example, on mobile browsers, the snapshot viewport overlays any shown UI like the URL bar and virtual keyboard:

The snapshot viewport overlaying UI in a mobile browser

On desktop browsers, a common UI widget requiring attention is scrollbars (in particular, left-side vertical scrollbars in RTL writing modes since it shifts the content origin). The snapshot viewport is overlays and fills the full content area:

The snapshot viewport underlaying scrollbars in a desktop browser

Positioning

The snapshot viewport serves as the common coordinate space in which transitions take place. Since each shared element's transition is positioned by its ::page-transition-container, and this element is positioned absolutely within the ::page-transition, we make ::page-transition match the snapshot viewport rect:

html::page-transition {
  position: fixed;

  /* Dynamically generated based on whether UI is showing or not. */
  left: -15px; /* left-side vertical scrollbar */
  top: -56px; /* mobile URL bar */
  width: 412px;
  height: 1000px;
}

When capturing a shared element's "screen space position", use the position relative to the snapshot viewport:

A shared element's position is captured relative to the snapshot viewport

Root snapshot

To avoid the root snapshot moving or scaling its snapshot is sized to match the snapshot viewport. The page's content is captured at its location within the snapshot viewport and regions of the snapshot covered by browser UI are rendered with the background color (or real page content, if available).

Content is rendered into the root snapshot at its snapshot viewport location

@khushalsagar khushalsagar added Agenda+ css-view-transitions-1 View Transitions; Bugs only labels Oct 11, 2022
@khushalsagar
Copy link
Member

This LGTM. I'm hoping the spec text can lean on ongoing work for viewport sizes, particularly large viewport size. @bramus FYI.

@bramus
Copy link
Contributor

bramus commented Oct 20, 2022

+1 on using “snapshot rect” as per web-platform-tests/interop-2022-viewport#27 (comment)

@khushalsagar
Copy link
Member

Here is the short proposed resolution: Use "snapshot viewport" for root element snapshot and UA CSS to size and position ::page-transition at snapshot viewport.

@astearns astearns added this to View transitions in October 26 meeting Oct 24, 2022
@atanassov atanassov moved this from View transitions to Shared Element Transitions in October 26 meeting Oct 25, 2022
@atanassov atanassov moved this from Shared Element Transitions to View transitions in October 26 meeting Oct 25, 2022
@jakearchibald
Copy link
Contributor

I created a series of examples here https://static-misc-3.glitch.me/set-viewport-examples/ to show how default transitions would handle these browser elements appearing/disappearing.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed Define transitions over changing viewport, and agreed to the following:

  • RESOLVED: Use "snapshot viewport" for root element snapshot and UA CSS to size and position ::page-transition at snapshot viewport.
The full IRC log of that discussion <emeyer> Topic: Define transitions over changing viewport
<emeyer> Github: https://github.com//issues/7859
<TabAtkins> bokan
<JakeA> "Bokan"
<emeyer> bokan: This relates to view transitions
<emeyer> …The issue is that when you’re performing a transitoin, the viewport size could change during the transition
<TabAtkins> +1 to this proposal
<emeyer> …For example, the mobile navigation bar or virtual keyboard could appear/disappear during transition
<emeyer> …Proposing a “snapshot viewport” that’s a rect which stays stabel in all cases
<emeyer> …We could position and size this so it goes under all the UI
<emeyer> …On desktop, we can have similar issues with scrollbars
<emeyer> …We would position this viewport under all that as well
<emeyer> …The coordinate space comes from ::page-transition
<emeyer> …When we capture elements, they’re all positioned relative to that rect, so it doesn’t matter if UI is shown or not
<emeyer> …The root snapshot is extended to fill the entire rectangle
<emeyer> …We don’t want page content to stretch because scrollbars appeared or disappeared
<Rossen_> q?
<emeyer> …There’s pretty good consensus amnong those working on this, but looking for feedback
<emeyer> astearns: Can things be padded with background rather than background color?
<emeyer> bokan: Yes, agreed.
<emeyer> argyle: This sounds a little hectic with things appearing and disappearing during a transition
<emeyer> …Should we define things appearing or disappearing to come before or after the transition?
<ydaniv> q+
<emeyer> …Second question: what if I want to keep UI elements in place until after the transition?
<flackr> q+
<emeyer> bokan: The URL bar in particular isn’t under author control for security reasons
<emeyer> …It is tricky with the URL bar coming in and being animated, the browser will have to coordinate things
<emeyer> …Idea is that when the URL bar comes in, it slides over content rather than pushing it around
<emeyer> …We thought about whether you can wait for UI elements to disappear before starting the transition
<emeyer> …We don’t want to delay animations, though
<Rossen_> q?
<iank_> for the cross origin case - is it ok that they might be at different (page) zoom levels?
<emeyer> argyle: What do Android apps do?
<emeyer> …Are there patterns we can look at there?
<emeyer> bokan: That’s a good idea, but if you’re doing an SPA, you can keep the keyboard up, but the URL bar is most out of authors’ control
<emeyer> ydaniv: You’re talking about the sizing of the viewport, it doesn’t matter if you have to scroll during the transition?
<emeyer> bokan: I don’t think we have to consider scroll here
<jensimmons> Please do research on iOS as well, not just Android.
<emeyer> ydaniv: Say I’m at the bottom of a list, and on the new page I need to scroll to the top
<emeyer> Rossen: Another example would be an anchor navigation
<emeyer> bokan: Normally we’d take a screenshot of where you are and another for where you’re going and then allow crossfade
<Rossen_> ack ydaniv
<Rossen_> ack flackr
<emeyer> flackr: Overall I think this looks good, one comment: whether we can show content behind the keyboard will depend on painted content
<jensimmons> q+
<emeyer> …The page has laid out to the size with the keyboard showing, so content underneath the keyboard was never intended to be exposed
<emeyer> …You can]t scroll to it or otherwise access it as a user
<emeyer> bokan: You can consider it’s as if you scrolled it up
<emeyer> …I think it’s fairly rare for pages to rely on height like that
<emeyer> flackr: I dfon’t think it’s that rare for application-like interfaces
<emeyer> s/dfon’t/don’t/
<emeyer> …The other thing is that offsets will be relative to top left of the new viewport; what if those change during the transition, say by hiding the URL bar
<emeyer> bokan: Input is blocked while transitioning, so you can’t hide the URL bar
<emeyer> …The three things affected are scrollbar, virtual keyboard, and URL bar
<emeyer> flackr: Maybe it’s a non-issue then
<PaulG> q+
<emeyer> bokan: I think if that becomes possible we’d have to have a way to fix the rect
<Rossen_> ack jensimmons
<emeyer> jensimmons: Since we’re designing for the web, we need to look at all the mobile OSes, so please do also look at iOS and other mobile OSes
<astearns> if we can do better than Android and iOS, then we definitely should (rather than matching current app behavior)
<emeyer> bokan: As far as we know, things work similarly between Android and iOS
<emeyer> …We are by default trying to make things more consistent
<Rossen_> ack PaulG
<emeyer> PaulG: A Bluetooth keyboard connected to a mobile device can immediately hide the virtual keyboard, so make sure you’re testing that case
<fremy> +1, this sounds good to me
<JakeA> khush:
<emeyer> khush: I put up a proposed resolution
<astearns> proposed resolution: Use "snapshot viewport" for root element snapshot and UA CSS to size and position ::page-transition at snapshot viewport.
<emeyer> Rossen: What doe sthe WG think about that proposed resolution?
<emeyer> fremy: I think this is a solid proposal and adjust as we find problems
<emeyer> Rossen: Any objections?
<emeyer> RESOLVED: Use "snapshot viewport" for root element snapshot and UA CSS to size and position ::page-transition at snapshot viewport.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
css-view-transitions-1 View Transitions; Bugs only Needs Edits
Projects
No open projects
October 26 meeting
View transitions
Development

No branches or pull requests

6 participants