Lea: not had time to look

Sangwhan: same

Hadley: user needs would be helpful. Jumps straight into how it works, features in android

Lea; they're assuming it's obvious, but it's not

Dan: there's a video.. Unclear what they're displaying

Lea: unclear why they can't do it with existing CSS transitions and animations, or an improvement that is incremental instead of a different API.

Dan: there's previous efforts but no alternatives examined in the explainer.

Lea: is it page navigation transitions?

Sangwhan: except it's not really a page, but a state transition between to pages in a SPA

Lea: transiiton between two states in a SPA can be done with CSS transitions already. If it's a page transition that cannot be done right now. Significant difference.

Sangwhan: I don't think it's a full page transition

Ken: it's called element transition

Sangwhan: they have this promise they're resolving and it seems like..

Lea: I would like explanation on why existing web platform tech can't deal with these use cases

Dan: it says with some work the above effects can be achieved with existing frameworks. But don't say what they mean by that.

Ken: maybe this is to make it easier. A lot of people have wanted something like this for a long time but couldn't have have figured out how to do it. We had other efforts in this area, navigation animations etc before. Navigation transition design.. about having these animations, if you load a new page it ends up in the same page so will look like a nice transition instead of one load, another load.. you can do it today but it's difficult and a lot of people have no idea how. THey should state that this is about making it easier to use for developers.

Lea: so it's about having a bunch of transitions so developers don't have to thinka bout which properties to animate to what values

Ken: so it's loading another page over the same thing, loading a different document, and those things will line up. From google search you can click something, it animates out and loads a different page

Lea: point is that CSS transitions are too low level

Ken: that would be my guess, but they should make that clear. Coordination between different pages to make sure everything just works. Scrolling etc.

Yves: isn't it more about page contexts?

Ken: previous effort was having different pages loading, something animated so it looks like a smooth transition. Especially the use case was that you don't always control everything so you have to coordinate, eg. between google search and google maps, and they'd like it to look very integrated.

Sangwhan: I'd love to see their explanation of use acses. Example code doesn't give us much of an idea.

Hadley: and what they're trying to accomplish

Lea: I can write a comment, what I'm hearing is they need to describe use cases, how existing web platform features do not cover these..

Ken: or how this makes it much easier or more approachable to developers

Lea: is it about making CSS transitions more approachable, or does it do something that CSS transitions can't do today?

Hadley: sounds like we have questins about the user needs, and the developer needs. May have opinions on either or both.

Lea: Right

Dan: if it's doing something in a more easy way, that can be done using CSS transitions, it should be built on top of CSS transitions, layered approach that we promote, rather than a separate thing. Important to ask if it does something CSS transitions can't do.

Lea: exactly

Ken: about coordination between different sites, if it's going to ease that. Seems to be coordination required between different documents if you want to animate something together. Is it making that easier? Thinking about previous efforts. Don't see much in this document and don't get the examples. Could imagine that you make an animation and the new page gets the values where it ended up so it can show something at that place.

Lea: [will comment]

Ken: they have this shared element.. trying to understand how it's shared.. oh its a selector list. Confused that it's called elements if it's a selector list.

Dan: looking at S&P..

Ken: loading new page in the background.. and it will animate between the old document and the new document. I think that is the new thing, you don't have access to two different documents. Example, document transition start, and give it a list of shared elements, and document new.. in prepare you give it the old one. So it's going to load the new one in the background?

Dan: the multi page API?

Ken: looking at shared element transitions example

Dan: they say the multi page API is still being designed, link to an issue

Ken: multi page is across origin?

Dan: SPA transition case has a working API, but MPA equivalent unsure, needs design. Linked from their S&P, their issue 2

Ken: not in the explainer. Second example looks designed to work across pages. Guess it could also work on the same page.

Dan: privacy issue they highlight is in the cross site navigation transition case... whether source and destination need to opt in to the API to learn about the content of the destination or vice versa. API allows customisation of UX when navigating between two sites. Is it okay without destination explicitly opting in to this behaviour? I'm on .... reddit, and I'm linking to CNN.. and both sites have opted in to use the transition API, and I then get some kind of animated transition that brings me to the CNN article. I don't get what the problem is.

Sangwhan: question about accessibility. Animations should be controllable as a preference.

Dan: Right.

Ken: this seems to be a specific API to do the flip animation that people are doing today. Abstract that a way,a nd maybe designed in a way that could work across documents.

Sangwhan: tricky bit is there has to be a story on how users can opt out of this. Don't see that here.

Lea: prefers reduced motion? Or a different opt out?

Sanghwan: yeah for example. No way to opt out, no accessibility story

Ken: can you do that with web animations today?

Sangwhan: I think so? If not, that's a bug.

Lea: idea is web devs are supposed to check the media query.

Ken: yeah

Lea: wouldn't be good if turning that optin on would blanket cancel any animation that's already running. Reduced motion is not zero motion, some is okay, some is slow, some might not result in any motion... I think it's okay to leave it up to the developer, but that's a different issue.

Dan: ask them to clarify the issue in the S&P. They've asked a question. Is it okay to show a transition to a shared element on a destination site without the site opting in. And I don't understand this case. I want them to flesh this out a bit.

Ken: seems a bit scary.. if you depend on another site to do animations.. no coordination is going to be terrible UX

Dan: I don't think this opt out.. need to clarify. I'll leave that as a separate comment.

Draft comment:

Hi there @ianvollick!
We looked at this today during a breakout and we had several questions for you:

- The explainer currently lacks a list of use cases, so it's difficult to assess whether this covers the user needs and developer needs it was designed to address, or even what these are.
- It was unclear to us whether this API adds new functionality that is not possible using existing Web Platform features (such as CSS transitions and animations, or Web Animations), or whether it's a higher level abstraction of commonly needed functionality that is already possible, just harder.
- It was unclear to us what the reasoning is for an entirely new API over a more layered approach over the existing Web Platform features mentioned above.

Could you please clarify?
``

(Punted from breakout C)

Lea: I asked if this could punted to plenary. I did take a closer look today. It does seem like something that needs solving and there is a need for it. But I am not quite sure how this proposed API is supposed to work. Seems that the primary need is for MPAs which is not specified here. Not sure this can be designed without that. Even the SPA case - there is a code example in the explainer. Not sure how this is suppsosed to work.

Rossen: on Tuesday during our CSS call - what was the overall outcome?

Lea: in general they were positive. I posted a link to Jake's talk. which talks about the problem statement but not about the API. So the working group was positive.

Tess: yes I think everyone understands the problem statement - the devil is in the details.

Lea: The review does show an API sketch.

Tess: why isn't this going to the CSS working group?

Rossen: procedurally - I think this is a case where they are engageing in an early preview- we have encouraged that in the past. This is the idea stage. At that altitude this is a good review to have - to justify the use cases and technical path forward. This feels like they are a bit more off-shore - they have already designed it and implemented - so this not an idea review. In which case I would expect a technical proposal.

Tess: at the beginning they say similar to material design principles -- there are other things that come to mind - e.g. in IOS. What about powerpoint? Transitions between slides... I would think they would look at slide to slide transitions in powerpoint and keynote...

Lea: The primary complexity is they are not just interested in transitions between pages - but also where specific elements in one page morph into specific elements in another page.

Tess: powerpoint (e.g.) does that.

Sangwhan: I don't see how the SPA version can evolve into an MPA version... based on the current design. Agree with the problem statement though.

Peter: I get the MP issue - but with a SP what does this do you can't do with CSS transitions?

Lea: more high level - this takes care of things that are hard with CSS transitions.

Sangwhan: the MP thing sounds like a complex problem.

Rossen: intended to work between pages that know eachother?

Lea: an open problem - an opt in where both pages could declare or maybe a limited set of transitions?

Sangwhan: would have to have a preload feature if you want to support MP...

Peter: unless both pages opt in and collaborate you'd have to clamp down on transitions - otherwise security issues

some responses to Lea's comments

Lea: sounds like multipage transitions are ones this is useful for but not speced yet. Seems like it's an essential part of this API..

Dan: not clear from the feedback if they are going to refactor to layer based on existing APIs or not...?

Lea: i will take a closer look let's revisit at the plenary.

[punted to plenary]

Ken: nice API...

[discussion on this issue - there is going to be a CSS breakout tomorrow on this topic...]

Ken: one thing missing is the use cases .. should be in the explainer...

[consensus that this not ready to close]

Dan: will more info come out of the CSS session?

Rossen/Lea: yes.

Resolved to wait until feedback from CSS session - bump to next week.

Lea: we delayed this because of a CSS wg breakout on this topic... . My takeaway so far - the discussions around these shared element transitions - without getting too low level into the detais... have not seen a complete proposal that addresses the multi-page transitions that is the primary use cases.. useful but doesn't address the thing people want fromt this feature... complete api needs to be there that does this. Don't think it's the time to discuss the implementation details without knowing what the API looks like. How do authors specify this transitions? this feels to me to be in brainstorming stage.

Dan: that kind of matches my estimation of this -- good idea, but both pages need to opt in, then what happens/ Isn't there a privacy issue massively?

Lea: we could figure out privacy issues with an actual API.. I don't think we have something to review. Even if there are no security issues anywhere there is still the problem of how you express these things? How you expose things? How do authors specify things?

Dan: is that surfaced in the discussion?

Lea: there is a lot of drilling down into details but not big picture

Dan: so we should raise the higher level issue?

Lea: I think so but I'd like feedback from others

Sangwhan: the really complicated case is not defined at all?

Lea: they see the problem that needs solving, but we can't review just the problem, we need to review a proposed solution as well

Sangwhan: the bit they gave us looks okay but the bit that was not defined at all is the one we should have to review intensively because it seems hard. But it's not defined at all.

Lea: I don't think it's wise to review the smaller part and leave the other part for future. Thye need to be designed together. The API should work for both cases, not two completely different APIs. Any time the web platform provided canned effects they ended up not being used becuase designers wanted to do their own thing - web platform should define primitives so designers can do what they want.

Dan: what's the current state of this issue? Feedback from tess and sangwhan in july.. responses to lea's comment..

Lea: in the actual TAG review the comment is good areas to look at for inspiration..

Dan: if we leave a comment to the tune of what you were saying just now could we do that and say come back to us when you've got more to review? Right now we don't feel there's enough of a concrete proposal here? Therefore could we close it? If we keep coming back to it and circulating on this issue but there's nothing further look at maybe we need to ask them to reopen when they have a more concrete proposal

Sangwhan: sure

Lea: makes sense. I can leave a comment.

Dan: let's do that, and close with that if it's okay, with prioviso to ask for it to be reopened when it's ..

Lea: what resolution?

Dan: too early

Sangwhan:

Apologies for the long delay! We discussed this at length during our VF2F, and while we think this would be a great addition to the platform, it's also a scary+open ended feature. The design itself I think makes a lot of sense and we are happy with it, but we'd like to see this being tried out in the wild (say, with some early adopters) and getting their feedback would be useful to know if there are details/features that we potentially missed in the initial design.

Do you think it would make sense to give it a trial run in the wild, and re-open after seeing what kind of feedback comes back? (presumably, also with updates to the design)