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