-
Notifications
You must be signed in to change notification settings - Fork 688
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
Comments
This LGTM. I'm hoping the spec text can lean on ongoing work for viewport sizes, particularly large viewport size. @bramus FYI. |
+1 on using “snapshot rect” as per web-platform-tests/interop-2022-viewport#27 (comment) |
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. |
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. |
The CSS Working Group just discussed
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. |
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:
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:
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:
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:When capturing a shared element's "screen space position", use the position 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).
The text was updated successfully, but these errors were encountered: