[CSSWG] Minutes TPAC 2023-09-13 Part II: View Transitions Breakout [css-view-transitions]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

View Transitions Breakout

  - In advance of the specific topics scheduled tomorrow, noamr gave a
      big picture overview of the current state of View Transitions and
      where it's trying to go in the future.
  - Some common cases seen today for view transitions are full page
      transitions, expanding details transitions, and animated layout
  - In the future, the desired state is to be able to do all of the
      above cases on a single page or a multiple page app.
  - There are still parts of the proposed future state that need more
      thought/investigation such as handling iframes and if the timing
      of actions could be problematic for a multi-page app.
  - Multi-page apps also bring specific challenges that will need
      special handling such as when the new page is not fully rendered


Agenda: https://github.com/w3c/tpac2023-breakouts/issues/20

  Elika Etemad
  Robert Flack
  Mark Foltz
  Vladimir Levin
  Romain Menke
  Eric Meyer
  Tim Nguyen
  Noam Rosenthal
  Khushal Sagar
  Bramus Van Damme

Scribe: vmpstr

CSS View Transitions Breakout

Support ViewTransitions for same-origin cross-document navigations
  github: https://github.com/w3c/csswg-drafts/issues/8804

  noamr: I'm going to present and chat about view transitions
  noamr: We have a few VT issues scheduled for tomorrow. I feel like we
         deal with these issues like blind men and an elephant
  noamr: we're not seeing the big picture and what we're trying to do
         with it
  noamr: and some people might have not been here
  noamr: I want to show where we are and where we want to go, and start
         a syntax discuss that we can continue tomorrow, so everyone
         has context
  noamr: I'll show what we have today, and plans for the future

  noamr: What is CSS view transitions (VT)
  noamr: It's a transition between states; before we had a transition
         between elements
  noamr: now we take a document capture it and morph it into a new state
  noamr: we do this by capturing an element snapshot, change the dom,
         capture a different set and morph by name
  noamr: This is a general idea of VT
  noamr: Here there's switching immediate. But if we put it inside
         start view transition, they get immediately a cross fade
  noamr: Now, this is a default and building on this we can define a
         whole bunch of customizations
  noamr: I wanted to show something similar to what we saw
  noamr: we have a button that switches states
  (live demo!)
  noamr: it does it immediately, if we add startViewTransition to it,
         and put it in the startViewTransition block, it cross fades
  noamr: This is nice, but you want to customize
  noamr: so for example, I'm giving h1s transition name of heading
  noamr: and then I can customize the animation between heading elements
  noamr: so now the animation is 1 second and has a blur
  noamr: I do all of this with pseudo elements
  noamr: The power here is that there is not just pseudo elements for
         the states together, but separate: one for the old state and
         one for the new state
  noamr: I'm defining that there is a slide but one of them is a reverse
  (this is still live demo)
  noamr: This is extremely customizable, there's something at the start
         and at the end, and pseudo elements to transfer between states
  noamr: This is css VT today in terms of features
  (back to presentation)
  noamr: It creates a morph by creating a tree of pseudo elements with
         names like heading in this case
  noamr: it creates a group for the transition, and a pair of elements
         old and new for the states
  noamr: People are excited about this, there are a few companies using
         this and frameworks;
  noamr: It's been a quite a popular request on surveys

  noamr: I want to jump from that to what we saw people do
  noamr: One thing that is very popular is a full page style, you set
         the page, you set the transition, you go to a different page
  noamr: You have one animating element that is root. Before the CSS VT
         you had to put both pages in the dom and use a transition group
  noamr: a11y wise it was where both states are in the DOM. Here there
         is no dom, it's pseudo elements and style
  noamr: This is a very common use case
  noamr: This is an even commoner use case. here is a list of songs,
         and you click one and expands to one song
  noamr: this is a list to details view, like shopping list to details
  noamr: This is extremely popular in demos that we have seen
  noamr: The third one is different: it's animated layout, you can put
         stuff in a grid or a list, give everything view transition
         names, and change their placement in the grid
  noamr: and this animates it
  noamr: This is less of a navigation, but something internal to the
         page. We see this in things like timeline where list changes
  noamr: Automatically sorting list is something we see a lot, and it's
         something I'm excited about
  noamr: It was not easy to do before, you had to create some ghost
         elements with transforms. it was not fun, depending on what
         fun is for you

  noamr: The constraints of CSS VT, where we are today, what you say
         looks demo-y
  noamr: It can be incorporated into a page, but it's limited to the
  noamr: Everything in the document you have, it will be selected for
         the document
  noamr: Also the whole document freezes, maybe you want just a widget
         to animate, and you don't want the whole page to lose pointer
         events etc
  noamr: and you saw that a lot of cases are navigation cases, but if
         you leave the document, then you lose the transition. You
         don't have a CSS state today that is cross document
  noamr: From this we derived what we want in the vision; we want to
         remove constraints

  noamr: To explain what we want to do, I want to show an ugly
         wireframe of a music list
  (demo slide)
  noamr: What you want on this page is three different transitions
  noamr: First you want the slide page thing, you want the nav bar
         where things slide on the next page
  noamr: then, if you click on a song, you want the song to expand
  noamr: the third if you drag and drop the list, you want the list to
  noamr: It doesn't look like an uncommon use case for a real web app
  noamr: When using VT myself, I was struggling with doing this:
         incorporate a bunch of things into the same app
  noamr: This is not in priority order, but this is what we envision
         for VT
  noamr: We think that we want to allow to scope element transitions to
  noamr: Second, semantically group: you have the same app with
         different grouping of animations. you have the slide animation
         and expand animation and you group all elements that
         participate in the animation semantically
  noamr: Number three, we want the transition to be triggered by a
         cross document navigation. We want transitions to work in the
         MPA. We definitely don't want view transitions to be a
         deciding factor for why people pick SPA
  noamr: We want it to work with javascript and without javascript
  noamr: Element scoped transitions, and by the way, all those three
         things is not because we're planning on doing them all in one
         go, but just when we design each one, we want to consider
  noamr: We don't want to spec ourselves into a corner
  noamr: Element scoped transitions is about animating a widget without
         stopping the whole page, so animate with drag and drop while
         the page is responsive
  noamr: Can't do this today, but want to do it in the future
  noamr: this is sort of how you do it in javascript
  noamr: So currently the document.startViewTransition function exist.
         We want to have something like playerWidget.startViewTransition
  noamr: and all those pseudo elements you saw, instead of being just
         on the html element, any element can be the originating
         element: #playerWidget::view-transition-group(play-pause)
  noamr: and all animations are scoped to that
  noamr: You might have simultaneous transitions running at the
         same time

  emilio: I wanted to ask about group. For top level VT in SPA
  emilio: View transition are fixpos / top layer, what is the rendering
          model for the scoped transition. A thing with view transition
          name would need a containing block etc
  khush: This is one of the things that we need to sketch out, like
         what constraints it needs. but what you saw on the previous
         slide, but what you saw before would happen in the iframe
  emilio: The iframe is a whole contained thing
  khush: The idea is to bring that type of containment into one element
  noamr: A lot isn't solved

  ntim: How does it work if you have a element that overlaps the scope,
        and you put it so it overlaps
  ntim: if you have your scope, and an element outside the scope, how
        does the screenshotting work
  noamr: The capture is of elements, not the screen and the overlap
         doesn't change
  yoav: So if there's occlusion, that doesn't change anything
  noamr: So you capture an element as an element capture, not the
         occluded screen capture
  noamr: With rendering and implementation for scoped element
         transitions, we'll have some challenges, but whenever we
         design the syntax for thing, we consider that the VT will not
         always be global
  noamr: Semantic grouping, defining multiple transitions, but
         activating just one of them
  noamr: when we click a nav bar, it does slide, but when you click an
         element it expands
  noamr: these would be different animations, different pseudo
         elements, etc
  noamr: A lot of people struggle with this, because they define too
         many names, and over-define things, or things work slowly
         because they have a bunch of elements
  noamr: we capture things that don't transition so you transition
         things that don't need to transition
  noamr: I've seen this from demos and that's something that we can fix
         and want to fix
  noamr: How do you fix it today? You can do it in javascript, say you
         want to click on details to expand
  noamr: you can set a class on <html> then run the transition and then
         remove the class
  noamr: during the transition you know which transition ran, so when
         you're in the expand song class, you know what names exist
  noamr: Instead we're suggesting when you startViewTransition you pass
         a list of ephemeral classes
  noamr: this is the CSS of how you would read these classes
  noamr: By the way, this is all bikeshed
  noamr: we thought about this a lot, but this is all bikesheddable

  emilio: One thing that jumps at me when I see that is that the way
          you do that means that you need to restyle the page
  emilio: and you can change a lot more than the view transition names
  [conversation is about making a selector vs qualifying the names]
  noamr: Doing something with a name is a possibility we felt it was a
         bit limiting
  emilio: In particular for MPA, you're about to nav away from the
          page, I'd rather avoid doing actual work that will do render
  noamr: You need to do render into a capture, and you have something
         with view transition name, but you don't want the text to
  emilio: I'm still sad about things that require layout
  noamr: Sure we can reason about doing this at the last moment
  noamr: but it's a drop in replacement for the html class name, but
         it's a good point, maybe we're allowing a lot of last minute
         things for MPA, but it's up the developers
  emilio: Sure

  michael: Is this ore about starting a subset of possible transition
           or customizing transitions or both
  noamr: Both
  michael: Once started the set will be on the whole document, the
           latter will allow multiple transitions
  khush: If your transition targets a whole document, but have multiple
  noamr: This is 100% syntactic sugar, and continuation of previous
         CSSWG F2F, if something starts with style and ends with style,
         it shouldn't be required to change the dom
  noamr: I think fantasai brought it up and it resonated with me
  noamr: If we decide to not do this, I'm ok with that too
  noamr: We have a type of the transition, and a slide one, and reason
         about them separately
  noamr: The reason we put it in the pseudo class because of the
         previous thing about scoped element transitions
  noamr: The active view transition pseudo element can go into element
         that is a view transition route
  noamr: The third one and most important one is navigation triggered
         transition -- automatically start a transition when a document
         navigation takes places
  noamr: (missed)
  noamr: Let's say we have the same app, and we have slide transitions
         and the song expands
  noamr: We want the song to be in a different document

  noamr: We've been working with modern frameworks like nextjs, you
         don't build your app as MPA or SPA, you just build your app
  noamr: and sometimes the choice is done did your document load, did
         you pass hydration to make it an spa
  noamr: so when I think about an SPA or an MPA, I want to think about
         it as a detail
  noamr: it's a progressive enhancement between different cases
  noamr: They don't want to rewrite their css for different cases, so
         it should be more infrastructure
  noamr: so we want the song to expand whether it's the same document
         or cross document and work consistently
  noamr: plus we don't want to break the sort transition while we
         do that

  noamr: So again, reminding of the bikeshed icon
  noamr: So we define something like an event or behavior that is
  noamr: we say if we're in the same origin navigation it's to trigger
         them rather than not trigger, can be called enable disable or
         what not
  noamr: The concept is you put this in css document in both documents
  noamr: and both sides opt in to trigger a transition
  noamr: We'd read it twice: right before the last frame of the old
         document, and before the first frame of the new document
  noamr: This also applies to back/forward cache and prerender
  noamr: we'd read the current value of this and decide whether to
         trigger or skip the transition
  noamr: We also need JS events or something to customize the
         transition, probably on both sides
  noamr: There is conversation with whatwg html spec to see if we can
         reach something
  noamr: but the idea is to have an event. the big use case is to have
         a new document that wants to use web animations not css
  noamr: then you get an event on the new document that can do that

  yoav: How is commit navigation be different in terms of negative side
        effects of unload
  noamr: We need to think about this, I'm hesitant to do this in unload
  yoav: Ok
  noamr: It has different things that are different, and alternative
         proposals. One is it's only same origin navigation, so you'd
         be in the same javascript loop.. you're in the app
  noamr: The other alternative is to send a same origin redirect
  noamr: so you get a navigation event for navigation API, and get a
         redirect event if it redirects
  yoav: Is it make it to be passive, or do we need to fire in the
        context of the old document
  noamr: It needs to request a frame of the old document and render
         into capture
  khush: One thing when we say the last frame is captured we need to
         define what your last frame, so we defer it until you have a
         navigation response
  khush: We are going to run a raf cycle and we tell the user this is
         the frame that will be captured, do your set up
  yoav: I'm not concerned about VT, but people using it for everything
        else. I want to maybe close down the event to be VT specific,
        but in the same way that we're limiting (missed) dismissal
  yoav: it would be good to have preventive restrictions
  noamr: We want to be careful of people creating VT just to get this
         event, so I'm hesitant with artificial restrictions
  yoav: I'm not saying artificial, I'm saying you get the event, but
        you can't do fetch or beaconing, etc
  noamr: That's ok
  noamr: we want to be careful that is general, we don't want to say
         it's VT specific, because it can have an opposite effect
  khush: What I'm confused: every raf is going to need to be
         restricted? since raf will fire
  yoav: Yeah, they'll queue raf and do weird things
  noamr: And people can do this in pagehide, we're adding an event
         before pagehide
  yoav: Ok

  noamr: We have challenges with MPA VT, one is progressive rendering:
         the incoming page might not be loaded/parsed
  noamr: second is how do you deal with the lifecycle and events and
  noamr: third one is in css: is navigation and event or a state, or
         you can say it's two events, because the state goes between
         two documents
  noamr: it's an event for the last frame and then for one more frame,
         so we're thinking more of it as an event than a state
  noamr: This is up for discussion
  noamr: This is also the first time where we define anything about
         navigations in css, so there was a fear of using a name like
         navigation for this
  noamr: This is about future proofing, maybe in the future we want to
         define something else here in the future, like regular
         keyframes that start on navigations
  noamr: maybe we want to qualify this with URLs or back/forward info
  noamr: So how do things work together, the three features we talked
  noamr: First, you can start a view transition and give it a class
  noamr: if cross document wants to be semantically grouped, we can add
         @navigation and specify view-transition-classnames behavior
  noamr: Now, our execution plan: we have two big issues we want to
         resolve soon
  noamr: first, global cross origin opt-in.
  noamr: second, the semantic grouping.
  noamr: I feel like if we have two those things, plus the html events,
         javascript style, and we resolve these two things in the
         lifecycle and people can play with MPA VT
  noamr: later on we plan to get to element view transition and expand
         navigation for url/back navigation/etc
  noamr: This is what we want to do first: navigation trigger for MPA,
         and readytorender event that maybe gives you a view transition
         that you can work with
  noamr: and semantic grouping where you set classes and respond to them
  noamr: step c is to combine these two things together
  noamr: questions? comments?

  michael: For cross document navigations, I understand the desire to
           limit the need for js, and there is a navigation api now and
           so you're potentially firing these events at a similar time
           to intercept
  noamr: Yes, for outgoing
  michael: So there is a problem for when to load, and end, and you
           have a placeholder like a spinner
  noamr: Yes, currently for the new document, this doesn't help us at
         all since there are no navigation events
  noamr: For old document we thought about dealing with navigate event
         but also adding something for redirects
  noamr: so you want this not just for things clicked in the page
  noamr: we do want to make this work well together

  fantasai: If you're just doing a declarative transition between
            pages, there is some type of syntax that enables that, some
            class navigation
  noamr: Right now, it's just @navigation same-origin
  fantasai: And what is same-origin what else can you put there?
  noamr: Right now nothing, but as a reader you can see this applies to
         same origin navigation, and later we'll be putting things that
         map to url patterns / back reload
  noamr: like you define what is a song page and play a page and a
         navigation between them has a class list expand
  noamr: We didn't want to get into this, but we had some ideas about
         this, navigation is always qualified by some urls, so you
         might have to specify something at least as broad as same
  noamr: We might also want to expand this to something that isn't same
         origin, we don't want existing pages to immediately upgrade to
         that without changes
  fantasai: I think it would be a good idea to fully explore the space,
            since the decision we make here we'll be trapping ourselves
            here, although we don't want to implement things we want to
            explore we'd want to put in here
  fantasai: In terms of mapping urls to classes of navigations, then
            can the page ... if you don't have the url or an obvious
            pattern, like it's a random identifier, which isn't great
            from url perspective but we shouldn't care, then you can't
            map a url pattern to types
  fantasai: Can we handle these cases
  noamr: We explored things to the group and we can explore this
         internally and explore it tomorrow
  noamr: this is about navigation urls and types which is (missed)
  noamr: About url patterns, we can go this way forever and in the end
         you can do things in javascript. If you can't map things
         declaratively you can do script (or in the server)
  noamr: we also don't want to work on the javascript api to work on
         this navigation

  eeeps: Is this feature limited to same origin navigations or is cross
         origin in scope
  noamr: Not in scope
  eeeps: But are there cases for this
  noamr: Maybe same site, or first party set
  noamr: Join us tomorrow for details

Received on Sunday, 8 October 2023 18:55:55 UTC