- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 8 Oct 2023 14:55:19 -0400
- To: www-style@w3.org
=========================================
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
transitions.
- 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
===== FULL MEETING MINUTES ======
Agenda: https://github.com/w3c/tpac2023-breakouts/issues/20
Present:
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
(presentation)
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
(demo)
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
order
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
document
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
animate
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
elements
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
everything
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
appear
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
transitions
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
bidirection
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
event
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
events
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
footguns
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
about
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
rule
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
origin
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